SEO su Wix: cosa puoi controllare davvero

Fare SEO su Wix è ancora considerato, da una parte del settore, una scommessa persa in partenza. È un pregiudizio con una data di scadenza scaduta da tempo. Negli anni in cui Wix costruiva siti in Flash, senza URL leggibili e senza alcun controllo sui tag di titolo, quella reputazione era meritata: i siti Wix erano oggettivamente difficili da indicizzare bene, e chi lavorava in SEO aveva buone ragioni per sconsigliarli. Quel Wix non esiste più da anni, ma la fama gli è rimasta addosso più a lungo della realtà che l'ha generata.

Oggi la piattaforma gestisce in modo competente i fondamentali: titoli e meta per pagina, slug modificabili, sitemap automatica, redirect, dati strutturati. Non è un giudizio entusiastico — è una piattaforma chiusa, e alcuni limiti restano strutturali indipendentemente da quanto la si configuri bene. Questo articolo separa le due cose: cosa puoi effettivamente controllare dentro Wix, dove il pavimento tecnico si ferma, in che ordine intervenire se non sei uno sviluppatore, e quando il limite smette di essere un fastidio e diventa un motivo reale per migrare.

Perché quella vecchia reputazione è nata (e perché non regge più)

Il problema originale era reale e concreto, non immaginario. Le prime versioni dell'editor Wix costruivano siti interamente in Flash: un formato che i motori di ricerca dell'epoca non riuscivano a leggere, quindi buona parte del contenuto era semplicemente invisibile per Google. A quello si aggiungeva l'impossibilità di modificare titoli, meta description o slug delle pagine: erano generati automaticamente e non negoziabili. Un sito costruito così non aveva, letteralmente, gli strumenti per fare SEO.

La piattaforma ha cambiato architettura da allora, spostando la costruzione dei siti su HTML renderizzato e aprendo un pannello SEO dedicato, editabile pagina per pagina. Chi ripete oggi che "Wix non si posiziona" sta descrivendo un prodotto che non esiste più. Detto questo, aggiornare i fondamentali non ha reso Wix equivalente a un CMS aperto: resta una piattaforma chiusa, con scelte di rendering e di struttura degli URL che l'utente non decide. La distinzione che conta non è "buono o cattivo", è "cosa è configurabile e cosa è fisso".

Cosa controlli davvero dentro l'editor

Dentro il pannello SEO di Wix, senza toccare codice, un proprietario di sito ha accesso a un set di leve che dieci anni fa semplicemente non esistevano, e che coprono buona parte del lavoro che altrove richiederebbe un plugin, un tema configurato con cura o l'intervento di uno sviluppatore:

• Titolo e meta description impostabili per ogni singola pagina, con anteprima di come appariranno nei risultati di ricerca.
• Slug dell'URL modificabile pagina per pagina, con l'eccezione delle sezioni a struttura fissa di cui parliamo più sotto.
• Sitemap XML generata e aggiornata automaticamente, senza bisogno di ricostruirla a mano a ogni pubblicazione.
• Gestione dei redirect 301 direttamente dal pannello, utile quando si cambia uno slug o si elimina una pagina.
• Markup per dati strutturati integrato per i tipi di contenuto più comuni — articoli di blog, prodotti, eventi — applicato senza scrivere JSON-LD a mano.
• Rendering mobile responsive di default, che elimina la necessità di gestire una versione mobile separata o di preoccuparsi della parità dei contenuti tra desktop e mobile.

Dove il pavimento tecnico si ferma

I limiti che restano non sono equivoci o pigrizia dell'utente: sono scelte architetturali della piattaforma, e nessuna configurazione del pannello SEO li rimuove.

Il primo riguarda il rendering e la distribuzione dei contenuti. Wix serve le pagine attraverso la propria infrastruttura, non attraverso un server che il proprietario del sito controlla direttamente. Per un crawler questo di norma funziona correttamente oggi, ma significa che non c'è margine di manovra su come e quando il contenuto viene generato: niente scelta del CDN, niente ottimizzazioni server-side su misura, nessun controllo diretto sugli header HTTP oltre a quello che il pannello espone.

Il secondo è un tetto di velocità sui template pesanti e sulle app installate. Un tema Wix ricco di animazioni, gallerie interattive o effetti di scorrimento porta con sé un payload JavaScript importante, indipendentemente da quanto sia snello il contenuto testuale. Ogni app aggiunta dal marketplace — una chat, un widget di recensioni, un popup, un'integrazione di terze parti — carica ulteriori script sulla pagina, e la maggior parte di questi script non è sotto il controllo diretto del proprietario in termini di timing o caricamento differito. Il risultato è un tetto di velocità che un sito con un template ricco difficilmente supera, per quanto si comprimano le immagini.

Il terzo sono le convenzioni di URL che non si possono aggirare del tutto. Alcune sezioni seguono pattern decisi dalla piattaforma: il blog vive tipicamente sotto un segmento di percorso fisso, e lo stesso vale per le pagine prodotto in un negozio Wix. La struttura gerarchica che un altro CMS lascerebbe progettare liberamente, qui è in buona parte predefinita. Per un sito editoriale con centinaia di articoli, o per un catalogo prodotti ampio che avrebbe bisogno di categorie annidate su misura, questo è il vincolo che si sente per primo.

Il quarto è l'accumulo di app, il cosiddetto app bloat. Il marketplace è comodo, ma ogni app aggiunta è un pezzo di codice in più che gira sulla pagina indipendentemente da quanto la si usi davvero. I siti costruiti nel tempo, aggiungendo un'app per ogni esigenza che si presenta, finiscono con un carico che nessuno ha deciso in un colpo solo: è la somma di dieci decisioni ragionevoli prese in momenti diversi.

L'ordine pratico se non sei uno sviluppatore

Non tutte le leve disponibili valgono lo stesso tempo. Per chi gestisce il sito da solo, senza supporto tecnico, ecco l'ordine che produce il risultato più alto per lo sforzo più basso — le prime tre voci richiedono in genere un pomeriggio di lavoro concentrato, le ultime due sono lavoro editoriale continuo, non una configurazione che si fa una volta e si dimentica:

• Correggere titoli e meta description delle pagine che portano traffico, o che dovrebbero portarne: è la modifica più veloce con l'impatto più diretto sul click-through dai risultati di ricerca.
• Verificare l'indicizzazione reale in Google Search Console, confrontandola con la sitemap generata automaticamente da Wix: le pagine escluse o non indicizzate vanno capite prima di ottimizzare qualsiasi altra cosa.
• Controllare il testo alternativo e il peso delle immagini: caricare foto non compresse è l'errore più comune sui siti Wix costruiti in modo visivo.
• Disinstallare le app non più usate attivamente: ogni app rimossa è codice in meno da caricare a ogni visita.
• Individuare i contenuti duplicati generati da filtri di categoria o da varianti prodotto, e usare i tag canonical dove il pannello lo permette.
• Rafforzare la struttura dei link interni tra le pagine del sito e gli articoli del blog: è la parte che dipende meno dalla piattaforma e più da come è organizzato il contenuto.
• Attivare i markup per dati strutturati già disponibili nativamente, invece di lasciarli spenti perché "va bene già così".

Quando la migrazione ha senso — e come mappare gli URL

Non tutti i limiti descritti sopra giustificano un cambio di piattaforma. Un negozio con trenta prodotti che gira lento perché ha otto app di marketing installate ha un problema di configurazione, non di piattaforma: rimuovere le app risolve la maggior parte del sintomo. La migrazione comincia ad avere senso quando il collo di bottiglia è strutturale e non correggibile dal pannello: un catalogo che ha bisogno di navigazione a faccette con URL propri, un volume editoriale che richiede una gerarchia di categorie che Wix non permette di costruire, o un requisito tecnico specifico — accesso ai log del server, un flusso di sviluppo basato su repository, un controllo granulare del file robots.txt — che la piattaforma non espone.

Se si arriva a quel punto, il lavoro che decide se la migrazione preserva il posizionamento acquisito o lo azzera è la mappatura degli URL, non la scelta del nuovo CMS. Gli URL di Wix seguono pattern fissi per sezione — gli articoli del blog e le pagine prodotto vivono sotto un segmento di percorso imposto dalla piattaforma — e quasi mai coincidono uno a uno con la struttura che il nuovo sito userà. Prima di spegnere il vecchio sito serve un elenco completo di ogni URL indicizzato, esportato da Search Console oltre che dalla sitemap, con accanto l'URL di destinazione corrispondente sulla nuova piattaforma. Ogni vecchio URL che sparisce senza un redirect 301 verso il suo equivalente nuovo è autorità di collegamento persa, non trasferita. Fatto bene, con la mappatura completa e i redirect impostati prima del cutover, la maggior parte del valore accumulato sopravvive al cambio di piattaforma; fatto in fretta, senza mappatura, è il modo più comune in cui un sito perde traffico proprio nel momento in cui il proprietario si aspettava un miglioramento.

Il limite reale, nella maggior parte dei casi

Vale la pena dirlo chiaramente, perché è la parte meno comoda da sentire: sulla maggioranza dei siti Wix che sottoperformano, il collo di bottiglia non è la piattaforma. È il contenuto — poco, generico, o scritto per un pubblico che non ha mai fatto una ricerca reale su quell'argomento — ed è la quasi totale assenza di link, interni ed esterni, che diano al sito un motivo per essere considerato autorevole su quel tema. Un sito con dieci pagine ottimizzate alla perfezione nel pannello SEO e nessun contenuto che risponda davvero a un'intenzione di ricerca non supera un sito con cento pagine imperfette ma utili. Prima di incolpare Wix per un posizionamento deludente, vale la pena controllare se il sito ha davvero dato ai motori di ricerca un motivo per posizionarlo — indipendentemente da quale piattaforma lo ospiti.