Ottimizzazioni di theme.liquid per la SEO di Shopify (vincono le soluzioni noiose)
In sintesi: Il vero vantaggio SEO in theme.liquid di solito consiste nel cancellare codice globale superfluo, non nell’aggiungere un altro snippet. Mantieni i segnali SEO universali nel layout, sposta il lavoro specifico della pagina nei template o nelle sezioni e fai in modo che l’HTML recapitato a Google sia veloce, pulito e il meno possibile dipendente da script di app.
Smetti di trattare theme.liquid come un plugin SEO
Anche io, all’inizio, cercavo subito il tag mancante. Cattiva abitudine. In mindnow, gli store Shopify con i problemi SEO peggiori raramente avevano bisogno di un altro snippet in theme.liquid; serviva togliere cinque vecchi snippet prima che Google e i clienti pagassero il loro prezzo su ogni pagina.
In un negozio il tema è stato incolpato di “brutta SEO su Shopify”. Il problema reale erano sei snippet di app, due blocchi schema duplicati e un feed di offerte prodotto incollato nel layout. Stesso schema su vadimkravcenko.com e seojuice.io: l’head deve descrivere la pagina, non gestire l’azienda.
«Liquid è un linguaggio di template open-source creato da Shopify e scritto in Ruby. È la spina dorsale dei temi Shopify e serve a caricare contenuti dinamici sullo storefront.»
Quella definizione conta perché attribuisce la colpa correttamente. Il colpevole non è Liquid. È il lavoro globale fatto con poca cura.
Cosa controlla di solito theme.liquid
theme.liquid è il wrapper di layout principale per la maggior parte delle pagine storefront (la shell intorno a template e sezioni). Contiene spesso il <head>, il content_for_header, riferimenti CSS, embed di app, tag di tracking, snippet schema, hint di preload e il markup di apertura del layout.
Proprio per questo quel file dovrebbe restare noioso. Se l’errore è in una sezione prodotto, danneggia le pagine prodotto. Se è in theme.liquid, si propaga ovunque.
Perché i file globali creano danni globali
I migliori risultati di ricerca colgono solo parte del problema. La documentazione performance di Shopify fornisce la base tecnica più solida. La guida SEO generale di Shopify spiega struttura, metadata e dati strutturati. Speed Boostr si avvicina al lavoro sulla velocità che i merchant percepiscono.
Quello che di solito non offrono è governance: cosa appartiene al layout, cosa ai template e cosa non avrebbe mai dovuto essere installato globalmente.
Solo gli elementi universali nei file universali
Questa è la regola per il resto dell’articolo. Gli elementi site-wide possono stare in theme.liquid. Logiche per prodotto, collezione, articolo, FAQ e breadcrumb dovrebbero vivere più vicino al template che le possiede.
Il lavoro SEO che appartiene a theme.liquid
La risposta non è “rimuovi tutto”. Shopify ha bisogno di un output head globale. Il tuo store ha bisogno di asset site-wide. Le analytics possono richiedere un caricamento conforme al consenso su tutto lo storefront. Il compito è mantenere il layout onesto.
Da tenere in theme.liquid |
Di solito NON qui |
|---|---|
Output lingua di base del tag <html> |
Schema specifico del prodotto hard-coded globalmente |
content_for_header |
Testo o metadata specifici di collezione |
| CSS globali e hint per risorse critiche | Ogni script di app su ogni template |
| JSON-LD Organization o WebSite site-wide | Schema duplicato di recensioni, offerte e breadcrumb |
| Tracking conforme al consenso | Logica di template che lancia loop costosi |
Conserva universali i segnali SEO universali
Il layout può ospitare in sicurezza segnali che descrivono l’intera azienda: lingua, viewport, output head richiesto da Shopify, framework di consenso, CSS core, magari Organization schema e WebSite schema con SearchAction se l’URL di ricerca è stabile.
Qui trovano posto anche alcuni hint di risorsa. Un singolo preload di font o un riferimento a CSS critico hanno senso globalmente. Cinque preload in competizione per immagini che appaiono solo in un template no.
Limita l’SEO specifica della pagina a template e sezioni
Lo schema Product va con i dati del prodotto. Article con gli articoli. FAQPage solo dove il testo FAQ è visibile. Breadcrumb in uno snippet breadcrumb o in una sezione consapevole del template.
Qui molti progetti di dati strutturati per e-commerce deragliano. Il merchant chiede “schema in Shopify”, qualcuno incolla JSON-LD in theme.liquid e ogni collezione, articolo e landing page inizia a fingersi un prodotto.
Non combattere l’output head obbligatorio di Shopify
content_for_header non è opzionale. È il tag con cui Shopify collega script di piattaforma, comportamento delle app, analytics e feature dello storefront. Non eliminarlo solo perché un waterfall report appare disordinato.
Audita però ciò che arriva tramite quel tag. App embed, estensioni tema e vecchio codice di app possono comunque aggiungere peso. La soluzione è la proprietà del codice, non il panico.
Esegui l’audit del layout prima di ottimizzarlo
Non modificare il tema live durante un picco di traffico. Consiglio basilare, ma è la frase che fa risparmiare più soldi.
- Duplica il tema.
- Apri
layout/theme.liquid. - Mappa ogni script, stylesheet, blocco schema, preload e include di app.
- Etichetta ogni voce come globale, specifica di template, di proprietà app o sconosciuta.
- Testa l’anteprima disabilitando gli script globali non essenziali.
- Sposta il codice specifico di pagina nel template o nella sezione corretta.
- Confronta l’HTML renderizzato su home, prodotto, collezione, pagina e articolo.
Crea la mappa del file
Copia il layout in un documento di lavoro e annotalo come una scena del crimine. Un negozio è arrivato da noi perché le collezioni sembravano lente e il test Rich Results di Google mostrava avvisi sui prodotti. La correzione è durata meno di due ore: schema Offer di prodotto sulle pagine collezione, due librerie A/B testing abbandonate e uno snippet di app recensioni disinstallata mesi prima.
Il tema era stato incolpato (capita spesso). Il file di layout portava solo fantasmi.
Separa codice globale da codice specifico di pagina
| Problema rilevato | Perché danneggia la SEO | Correzione più sicura |
|---|---|---|
| JSON-LD Product appare sulle pagine collezione | Confonde i parser di dati strutturati | Spostalo nel template prodotto |
| Tre app recensioni emettono schema | Duplica o confligge il markup prodotto | Scegli una sola fonte |
| Widget chat caricato ovunque | Aggiunge JS prima che esista intento d’acquisto | Caricalo dopo interazione o su template selezionati |
| Hero image lazy-loaded | Può ritardare LCP | Carica eagerly i media above-the-fold |
| Ordinamento dentro loop Liquid | Spreca lavoro di render | Ordina prima del loop |
Tratta gli snippet di app sconosciuti come colpevoli finché non testati
Sconosciuto non significa negativo. Significa senza proprietario. Se nessuno sa spiegare perché uno snippet sia in theme.liquid, disattivalo in un tema duplicato e testa i flussi: menu, ricerca, form prodotto, carrello, passaggio al checkout, recensioni, tracking e consenso.
Qui un audit SEO tecnico reale batte una checklist. Il rischio raramente è una sola riga sbagliata. Sono cinque tool decenti che credono tutti di meritare priorità globale.
Pulisci gli script senza rompere lo storefront
«JavaScript non dovrebbe essere necessario per le funzionalità di base del tema, come trovare o acquistare prodotti.»
Quella frase di Shopify è lo standard. Se menu, form prodotto, selezione varianti, ricerca o carrello dipendono da uno script bloccante che fallisce silenziosamente, non hai solo un problema SEO. Hai un problema di storefront.
«Gli storefront Liquid sono molto veloci»
Lo ha detto Sia Karamalegos sul blog performance di Shopify, e l’implicazione è scomoda. Gli store lenti spesso lo sono perché i merchant aggiungono lavoro globale a ogni rotta. Le app lasciano codice dopo la disinstallazione — a volte per anni — e il file di layout continua a servirlo.
Il bloat da app è spesso globale prima che visibile
Widget recensioni, chat, script A/B testing, heatmap, loyalty, bundle, personalizzazione e popup amano il layout. Alcuni richiedono accesso globale. Molti no.
Parti dagli app embed nell’editor tema, poi ispeziona content_for_header, poi cerca include che citano vecchi nomi di app. Se un’app riguarda solo le pagine prodotto, il suo codice non dovrebbe girare su articoli e collezioni.
Defer con cautela, non alla cieca
Differire gli script può aiutare. Può anche rompere selezione varianti, tracciamento consenso, attribuzione analytics, selettori valuta e rendering recensioni. Testa in anteprima prima di pubblicare.
Una strategia sicura è banale: rimuovi prima il codice morto, ritarda i widget marketing fino all’interazione, deferisci gli script non critici solo dopo i test e mantieni la scoperta prodotto funzionante senza JavaScript quando possibile (nel 2026 non è più opzionale).
Rendi possibile l’acquisto senza JavaScript
JavaScript può migliorare l’esperienza, ma non deve essere l’unico percorso di revenue. I link prodotto devono essere indicizzabili, le pagine di ricerca devono mostrare risultati, l’add-to-cart deve degradare in modo sicuro. Gli URL di variante e le opzioni selezionate non devono diventare invisibili a crawler o clienti.
Se stai combattendo costi di hydration o contenuti prodotto renderizzati client-side, leggi una guida JavaScript SEO prima di incolpare Liquid. Il problema di rendering potrebbe essere nello strato app, non nel linguaggio del tema.
Misura con dati reali, non con punteggi di ego
«PageSpeed NON è un buon modo per misurare la velocità di un negozio.»
Kurt Elster è schietto per un motivo. Un punteggio alto che rompe tracking, recensioni o varianti non è una vittoria; un punteggio basso che indica un vero ritardo LCP è utile. Il punteggio è un indizio, non il KPI.
Correggi i dati strutturati in Liquid senza creare duplicati
«Preferiamo attualmente il markup JSON-LD. La maggior parte dei nuovi dati strutturati esce prima in JSON-LD. È ciò che preferiamo.»
Il punto di John Mueller chiude il dibattito sul formato per la maggior parte degli store Shopify. Usa JSON-LD. La domanda più difficile è la proprietà.
JSON-LD è preferito, ma prima viene la proprietà
Molti post SEO su Shopify dicono “aggiungi schema”. È un consiglio incompleto. Se il tuo tema, l’app recensioni, l’app feed prodotto e l’app SEO emettono tutti schema Product, il problema non è più il formato.
Scegli un solo proprietario per ogni tipo di schema. Poi rimuovi o disattiva gli altri.
Quale schema può essere globale
| Tipo di schema | Collocazione consigliata |
|---|---|
| Organization | theme.liquid o snippet globale |
| WebSite con SearchAction | theme.liquid se la ricerca è stabile |
| Product | Template prodotto o sezione prodotto |
| BreadcrumbList | Template o snippet breadcrumb |
| Article | Template articolo blog |
| CollectionPage | Template collezione |
| FAQPage | Solo pagine con contenuto FAQ visibile |
Lo schema prodotto non va hard-coded nel layout
Lo schema Product richiede titolo, immagine, descrizione, SKU, prezzo, disponibilità, varianti, brand, offerte e a volte dati recensione. Quel contesto non esiste su ogni pagina.
Le app recensioni meritano sospetto speciale. Spesso iniettano markup Product, AggregateRating, Offer e Review. Se anche il tema emette quei campi, gli strumenti per rich result possono mostrare conflitti anche quando la pagina sembra a posto.
Testa con entrambi gli strumenti Google
Usa il Rich Results Test per vedere l’idoneità alle funzionalità Google. Usa lo Schema Markup Validator per controllare la validità più ampia dei dati strutturati. Testa la pagina renderizzata, non un frammento incollato dal file tema.
Rendi i loop Liquid più economici prima che diventino sintomi SEO
«Se vuoi ordinare i prodotti di una collezione per prezzo, fallo prima di iterare sui prodotti e non all’interno del loop.»
Questa indicazione Shopify sembra piccola. Non lo è. Problemi di performance Liquid si nascondono spesso negli snippet chiamati da theme.liquid: header, mega menu, barra annunci, selettore lingua, strip di raccomandazioni o un carousel collezione globale.
Il layout è lento spesso per snippet inclusi
Il file layout può sembrare pulito mentre gli snippet inclusi fanno il lavoro costoso. Un mega menu può ciclare tra collezioni su ogni pagina. Un header può interrogare dati prodotto non visualizzati. Un selettore lingua può ripetere logica che doveva essere assegnata una sola volta.
Osserva all_products, menu grandi, lookup metafield ripetuti e loop annidati. Il problema raramente è un singolo loop, ma la ripetizione su ogni rotta.
Sposta il lavoro fuori dai loop
Ordina prima del loop. Filtra prima del loop. Assegna valori ripetuti una sola volta quando migliora la chiarezza. Limita i loop quando servono solo quattro elementi.
Il pattern sbagliato è: ciclare su ogni prodotto, poi decidere all’interno del loop quali prodotti importano. Il pattern migliore è: preparare prima l’insieme rilevante, poi iterare su quello ridotto.
Mantieni noiosa la logica di navigazione e header
I mega menu sono una tassa frequente sulle performance SEO. Sembrano navigazione, si comportano come query di dati site-wide.
Mantieni la logica dell’header prevedibile. Se il menu ha bisogno di card promozionali ricche, rendile impostazioni esplicite invece di lookup dinamici su tutto il catalogo.
Correggi il caricamento immagini dal layout in giù
«Qualsiasi elemento above-the-fold non dovrebbe essere lazy-loaded.»
Quella frase di Shopify dovrebbe stroncare molti consigli sbagliati sulle immagini. Il lazy loading indiscriminato sembra furbo finché l’hero, i media prodotto o il banner collezione — candidati LCP — restano in attesa troppo a lungo.
L’immagine LCP non deve attendere
Non fare lazy-load dell’immagine probabile LCP. Fornisci a Shopify larghezza e altezza sufficienti per prevenire layout shift. Usa output immagine responsive tramite filtri e tag immagine Shopify, non un asset sovradimensionato.
Precarica solo l’immagine davvero prioritaria, non cinque asset in competizione. Il preload è una promessa al browser: tradiscila troppo spesso e creerai un collo di bottiglia diverso.
Il lazy loading globale è uno strumento grossolano
Molte app immagini applicano una sola regola ovunque. La decisione corretta dipende da template e posizione. Una miniatura galleria sotto la piega può attendere. La prima immagine prodotto di solito no.
Collegalo a theme.liquid: hint di risorsa globali e script di lazy loading spesso stanno lì, ma la decisione giusta appartiene più vicino alla sezione che renderizza l’immagine.
Tag head, canonical e robots hanno bisogno di protezioni
I tag SEO classici contano ancora. Diventano rischiosi quando un file layout tenta di controllare ogni template con una lunga catena di condition.
Canonicals e robots devono essere intenzionali
Usa l’output canonical integrato di Shopify dove possibile. Non hard-codare un pattern unico per tutti i template. Ordinamenti, paginazione, filtri di collezione e URL prodotto richiedono gestione consapevole del template.
I directive robots dovrebbero essere rari e ovvi. Un tag canonical duplicato — quello che confligge silenziosamente con l’output integrato Shopify — può restare inosservato per mesi. Un noindex fuori posto può fare più danni in una pubblicazione di uno script app lento.
Ho spedito anch’io uno di quei lunghi alberi conditional (e l’ho sbrogliato dopo un update app). Alcune condition vanno bene. Un layout che finge di essere un CMS è un campanello d’allarme.
L’HTML renderizzato è la risposta finale
Non fidarti solo della vista sorgente. Ispeziona l’HTML renderizzato (l’URL corrente dopo l’esecuzione browser) e verifica title, description, canonical, robots, hreflang se usato e dati strutturati.
Se un’app riscrive i tag dopo il load, Google potrebbe comunque renderizzarli, ma hai reso un segnale semplice dipendente dal timing client-side. Evitalo se esiste un’opzione più pulita.
Come testare se le modifiche a theme.liquid hanno aiutato la SEO
I test devono confrontare gli stessi template prima e dopo. I miglioramenti in home non provano miglioramenti nelle pagine prodotto. I miglioramenti prodotto non provano che i template articolo siano rimasti puliti.
| Test | Cosa ti dice |
|---|---|
| Visualizza HTML renderizzato | Se Google vede tag e contenuti finali |
| Ispezione URL Google | Se Google ha indicizzato ciò che pensi |
| Rich Results Test | Se i dati strutturati sono validi per i rich result |
| WebPageTest | Waterfall, candidato LCP e file che bloccano il render |
| Pannello Performance Chrome | Long task e costo script |
| Core Web Vitals in Search Console | Trend dei dati di campo |
| Anteprima tema Shopify | Confronto sicuro prima del publish |
Confronta prima e dopo sugli stessi template
Testa home, prodotto, collezione, pagina, articolo e ricerca. Cattura HTML renderizzato, candidato LCP, CLS, long task, canonical, robots e output schema.
Su seojuice.io mi interessa meno un punteggio lab perfetto e più che l’HTML venga servito pulito, il canonical sia stabile e la pagina non faccia aspettare Google per capire il contenuto via client-side.
Osserva Search Console dopo la pubblicazione
«Un sito buono e veloce non fa male. Un sito lento non aiuta. Non è l’alfa e l’omega che si racconta.»
La sintesi di Kurt Elster è la più sensata. La velocità supporta la SEO. Non sostituisce contenuti, link, domanda o merchandising.
Dopo il publish, monitora indicizzazione, miglioramenti, merchant listing, snippet prodotto e Core Web Vitals in ottica e-commerce. Aspettati ritardo nei dati di campo. Gli strumenti lab reagiscono subito; Search Console richiede tempo.
Checklist SEO sicura per theme.liquid
- Duplica il tema prima delle modifiche.
- Mantieni
content_for_header. - Rimuovi gli snippet di app inutilizzati.
- Sposta schema di prodotto, articolo, collezione e FAQ fuori dal layout globale.
- Conserva in
theme.liquidsolo lo schema davvero site-wide. - Non fare lazy-load dell’immagine LCP.
- Differisci o ritarda script non critici solo dopo i test.
- Garantisci discovery prodotto e acquisto utilizzabili senza JavaScript obbligatorio.
- Sposta ordinamento e filtro fuori dai loop Liquid.
- Verifica l’HTML renderizzato dopo ogni cambiamento rilevante.
- Valida i dati strutturati.
- Confronta LCP, CLS e long task prima e dopo.
- Monitora Search Console per cambiamenti di indicizzazione o enhancement.
L’obiettivo non è un theme.liquid ingegnoso. L’obiettivo è un layout noioso che permetta a ogni template di fare il proprio lavoro.
FAQ
theme.liquid influisce sulla SEO di Shopify?
Sì. Può influire su chiarezza di crawl, dati strutturati, costi di render, Core Web Vitals, canonical, tag robots e peso script. Il pericolo è che un singolo errore nel layout colpisca la maggior parte delle pagine storefront.
Dovrei aggiungere codice SEO a theme.liquid?
Solo se il codice è davvero site-wide. Schema Organization, schema WebSite, output lingua e l’output head richiesto da Shopify possono stare lì. Logiche specifiche di prodotto, articolo, FAQ, breadcrumb e collezione di solito no.
Posso rimuovere content_for_header per velocità?
No. Tienilo. Audita le app e gli embed che aggiungono codice tramite quel tag, ma non rimuovere l’output head obbligatorio di Shopify.
Perché il mio schema Shopify mostra duplicati?
La causa tipica è la molteplicità di proprietari. Tema, app recensioni, app SEO o app feed possono tutti emettere markup Product, Offer, Review o AggregateRating. Scegli una sola fonte e disabilita le altre ove possibile.
PageSpeed Insights basta per testare le modifiche SEO su Shopify?
No. Usalo come un input diagnostico (non solo un punteggio). Testa anche HTML renderizzato, Ispezione URL, Rich Results Test, WebPageTest, Performance Chrome e dati di campo in Search Console.
Vuoi un layout Shopify più pulito?
SEOJuice può aiutarti ad auditare la configurazione Liquid SEO del tuo Shopify, identificare cosa deve restare globale, cosa spostare nei template e cosa eliminare in sicurezza. Se il theme.liquid del tuo store è diventato un cimitero di app, parti dal layout prima di aggiungere un altro snippet SEO.
Read More
no credit card required