Pacchetto SEO tecnico

Il SEO Technical Pack è il pacchetto di moduli SEO PrestaShop dedicato ai segnali tecnici che Google usa per scansionare, comprendere e consolidare il tuo negozio. Riunisce quattro nostri moduli: Advanced SEO Sitemap Builder per le sitemap XML/HTML, Automatic SEO Schema Rich Snippets per i dati strutturati Schema.org, Product Canonical Manager per il controllo di canonical e noindex e Hreflang Tags Manager per il targeting multilingua.

Si distingue dalla Smart SEO Revolution Suite completa perché resta sull'infrastruttura, non su ogni flusso SEO. Scegli questo pack quando la priorità è la scoperta delle pagine, i dati strutturati, il controllo dei contenuti duplicati e il corretto targeting linguistico, senza comprare ogni modulo tecnico singolarmente.

Una sitemap XML è un file machine-readable scritto per i motori di ricerca. Elenca URL insieme a metadati (data last-modified, alternate hreflang, riferimenti immagine) e viene inviata a Google Search Console o Bing Webmaster Tools. Il suo compito è la scoperta: aiutare i crawler a trovare e prioritizzare pagine che potrebbero altrimenti perdere.

Una sitemap HTML è una pagina normale del tuo shop, pensata per visitatori umani. Elenca link a categorie, prodotti, pagine CMS e produttori in una struttura leggibile. Il suo compito è navigazione e internal linking, offre ai visitatori un indice di riserva e ai crawler un altro set di link verso pagine più profonde.

In genere vuoi entrambe: la sitemap XML è quella che i motori di ricerca consumano davvero, mentre la sitemap HTML è opzionale ma utile su cataloghi grandi. Il nostro Advanced SEO Sitemap Builder genera sitemap XML con alternate hreflang e voci immagine, divide automaticamente i cataloghi grandi al limite dei 50.000 URL per file imposto dai motori di ricerca in un indice sitemap, e può pubblicare anche una pagina sitemap HTML.

Il sitemap builder non è solo un dump di URL. La sua descrizione modulo e pipeline sono costruite intorno a sitemap XML verificate: gli URL possono essere scansionati e controllati per status HTTP, canonical e noindex prima di essere scritti. Le righe URL salvate includono tipo entità, lingua, shop, status, canonical e metadati immagine/hreflang, così la sitemap finale può basarsi su URL che hanno superato la verifica invece che su ogni URL di catalogo possibile.

Per l'output XML, il writer include il namespace standard sitemap e aggiunge namespace image e XHTML quando l'output immagine o hreflang è attivo. Ogni URL può ricevere <loc>, <lastmod>, <changefreq>, <priority>, voci immagine e link di lingua alternata. Output grandi sono divisi per conteggio massimo URL e dimensione file configurati, e un indice sitemap punta i crawler ai file generati.

La sitemap HTML è diversa per design. Usa URL verificati per shop e lingua correnti, li raggruppa per tipo come home, product, category, CMS, manufacturer, supplier, core, hook o custom, e li renderizza come una pagina normale. Nel front controller ispezionato la pagina sitemap HTML è marcata noindex, quindi trattala soprattutto come pagina di navigazione utente e internal linking, non come un'altra landing page che ti aspetti ranki.

Per i merchant, la configurazione pratica è: abilita i tipi entità che vuoi davvero indicizzare, mantieni attivi output immagini e hreflang per cataloghi multilingua/ricchi di immagini, invia l'indice sitemap XML in Search Console e linka la sitemap HTML solo dove aiuta i visitatori.

In breve: Yoast è un plugin WordPress e non ha un equivalente in PrestaShop, quindi lì non c'è nulla da integrare. Se intendi un altro modulo SEO per PrestaShop, i nostri moduli possono funzionare accanto a esso; va solo gestita la sovrapposizione.

Il rischio con due strumenti SEO è l'output duplicato: due tag canonical, due set di tag Open Graph, due blocchi JSON-LD. Ai motori di ricerca non piace. Decidi, funzione per funzione, quale strumento fa da riferimento e disattiva il duplicato nell'altro.

I nostri moduli sono progettati per cooperare, non per andare in conflitto. La Smart SEO Revolution Suite rimuove attivamente i duplicati rispetto al tema: quando genera i propri tag hreflang o Open Graph, toglie dall'head i tag equivalenti del tema e può anche pulire, in opzione, il JSON-LD esterno. Blog Revolution va oltre e affida i dati strutturati del blog a SEO Revolution quando quel modulo deve emetterli, così non avrai mai due schema del blog.

Errore comune: attivare la stessa funzione in due moduli pensando che «di più sia meglio». Scegli un solo responsabile per funzione e l'output resterà pulito e singolo.

Un warning di markup mancante significa che il tool non ha trovato quel tipo schema o campo richiesto su quell'URL. In Schema Revolution, controlla prima che il tipo schema sia abilitato per quel tipo pagina, poi confronta la preview del modulo con il sorgente finale della pagina dopo aver svuotato la cache, e infine testa l'URL live nel Rich Results Test di Google o nel validator Schema.org.

Il modulo costruisce JSON-LD in base al tipo pagina rilevato. A seconda della configurazione può emettere Organization e WebSite sulla homepage, BreadcrumbList sulle pagine interne, Product schema sulle pagine prodotto, CollectionPage per categorie e Article per pagine CMS. Product schema può includere nome, URL, descrizione, SKU, GTIN, MPN, brand dalla fonte catalogo configurata, immagini, condizione, offerte, disponibilità, dettagli spedizione, politica di reso, rating, recensioni, peso e dati categoria quando lo shop possiede quei dati.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example product",
  "url": "https://example.com/product.html",
  "description": "Short product description",
  "sku": "REF-123",
  "gtin13": "1234567890128",
  "offers": {
    "@type": "Offer",
    "price": "29.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Se Google segnala campi mancanti, confronta tre cose: preview del modulo, sorgente HTML finale dopo aver svuotato cache PrestaShop ed esterne, e URL live recuperato dal tool di test. Un campo può essere assente perché il tipo schema è disattivato, il rilevatore del tipo di pagina non identifica la pagina come previsto, al prodotto mancano dati sorgente come brand o GTIN, HTML in cache è ancora servito, oppure un altro tema/modulo cambia l'output finale.

Attenzione alle opzioni di pulizia. Sono pensate per rimuovere microdata vecchi e JSON-LD duplicato, ma l’attuale pulizia del JSON-LD preserva solo script marcati con <!-- mprschema -->, mentre l'output header del modulo non è marcato. Con clean_existing_jsonld abilitato, incluso il suo stato predefinito, la pulizia può rimuovere lo schema del modulo stesso dall'HTML finale. Se i tool mostrano schema mancante, disattiva/correggi la pulizia del JSON-LD o aggiungi il marker atteso prima di presumere che la colpa sia di un altro modulo.

Nella configurazione del modulo, apri Schema Revolution > Configuration > Schema Types. Abilita lì il tipo mancante: Product Schema, Organization Schema, WebSite Schema, Breadcrumb Schema, Category Schema o CMS Article Schema, a seconda dell'URL testato.

Se lo schema esiste nell'anteprima ma scompare dall'HTML finale, disattiva Remove Existing JSON-LD nella stessa scheda Schema Types durante i test. Questa opzione rimuove dalla pagina gli script application/ld+json non marcati prima dell'output, quindi è la prima impostazione da controllare quando i validator segnalano che tutto il JSON-LD è mancante.

I tag hreflang risolvono bene un problema specifico: dicono a Google quale versione linguistica o paese di una pagina mostrare a ciascun visitatore, così le pagine tradotte smettono di competere tra loro come contenuto quasi duplicato. Per uno store PrestaShop multilingua non sono opzionali, ma sono una parte del lavoro, non tutto il lavoro.

Ciò che hreflang non farà è salvare traduzioni povere di contenuto o di qualità tipica della traduzione automatica, riempire pagine che esistono solo in una lingua o correggere strutture URL incoerenti tra shop. Queste cose richiedono contenuto reale e URL puliti sotto i tag. La nostra Smart SEO Revolution Suite genera hreflang automaticamente per ogni lingua attiva, aggiunge un x-default corretto, tiene conto del contesto di ciascun negozio nel multinegozio e include gli stessi riferimenti anche nella sitemap XML. Metti a posto quei segnali e Google può abbinare la versione corretta a ogni utente che effettua una ricerca; la qualità della traduzione resta una tua responsabilità.

Nella SEO Suite, l'output hreflang fa parte dell'header hook. Quando HREFLANG_ENABLED è attivo, il modulo chiama il suo Hreflang manager e renderizza tag <link rel='alternate' hreflang='...'> per gli URL alternate che può costruire. Se esiste più di un'alternata, aggiunge anche un URL x-default. Se la decisione robots corrente contiene noindex, la suite non restituisce output hreflang per quella pagina, evitando che pagine noindexed mandino segnali misti.

<!-- MPR SEO Revolution - Hreflang Tags -->
<link rel="alternate" hreflang="en-US" href="https://example.com/en/product.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product.html" data-mpr-seo="1" />

<url>
  <loc>https://example.com/en/product.html</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" />
</url>

Il lato sitemap è separato ma allineato. Il writer sitemap può emettere voci xhtml:link rel='alternate' quando trova URL corrispondenti per la stessa entità in altre lingue. La configurazione sitemap ha uno switch INCLUDE_HREFLANG, quindi hreflang in header e hreflang nella sitemap XML possono essere entrambi controllati consapevolmente.

Ci sono comunque limiti reali. Hreflang funziona solo quando esiste un URL alternativo reale a cui puntare. Se un prodotto esiste in inglese ma il prodotto francese manca, è disattivato, noindexed o ha contenuto tradotto scadente, il tag non può creare per te una buona landing page francese. Allo stesso modo, hreflang non sostituisce i tag canonical; ogni pagina lingua dovrebbe normalmente canonicalizzare se stessa e poi elencare le proprie alternate.

Una buona checklist SEO multilingua: mantieni crawlable ogni URL lingua, usa canonical autoreferenziali, pubblica traduzioni complete per prodotti e categorie importanti, mantieni coerenti gli URL dello switcher lingua, includi le alternate nella sitemap XML ed evita noindex sulle pagine che devono partecipare al cluster hreflang.

Sì. La Smart SEO Revolution Suite è il nostro modulo SEO tutto-in-uno per PrestaShop: riunisce la nostra linea SEO principale in un'unica dashboard del back office, con una sola licenza e un solo canale di aggiornamento, così non devi gestire più moduli ognuno con la propria pagina di impostazioni.

La Suite offre ciò che fanno questi moduli singoli, più degli extra:

• Advanced SEO Sitemap Builder, sitemap XML/HTML, hreflang e voci immagine, con suddivisione automatica al limite di 50.000 URL.
• Automatic SEO Schema Rich Snippets, markup Product, Offer, BreadcrumbList, Organization, Article, FAQ e Review.
• Product Canonical Manager, canonical, hreflang e controllo noindex/nofollow.
• Automatic Internal SEO Linker, suggerimenti di linking interno da parola chiave a URL su tutti i contenuti.

In più aggiunge modelli di title/description con segnaposto, un gestore di redirect 301/302/410 con log degli accessi, il monitoraggio dei 404, editor per robots.txt e llms.txt, output Open Graph e Twitter Card, l'import di Google Search Console e la generazione meta in blocco con IA tramite OpenAI, Claude o Gemini.

La logica d'acquisto è semplice: se ti serve solo una funzione isolata, ad esempio solo i canonical, il modulo singolo corrispondente può essere la scelta più snella. La Suite raggruppa queste funzioni SEO in un solo modulo e un'unica dashboard, quindi confrontala con i moduli singoli in base alle funzioni che ti servono davvero.

Tante quante ne servono al tuo negozio. Advanced SEO Sitemap Builder non usa un numero fisso di file sitemap e non nomina i file figli per tipo di entità. Raccoglie le sorgenti URL abilitate, le verifica, scrive file XML a blocchi e poi scrive un indice sitemap per il negozio.

Per impostazione predefinita il modulo include prodotti, categorie, pagine CMS, pagine core, immagini prodotto e alternate hreflang. Anche produttori e fornitori sono sorgenti URL disponibili, ma sono disabilitati di default nelle impostazioni iniziali del modulo. Il writer divide l'output quando viene raggiunto il limite URL configurato, con 50,000 URL per file come default, e protegge anche il limite di dimensione file da 50 MB del protocollo sitemap.

Example generated files for shop ID 1:
modules/mprsitemapbuilder/sitemaps/sitemap_index_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_3.xml

<sitemapindex xmlns='http://www.sitemaps.org/schemas/sitemap/0.9'>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Invia solo l'URL dell'indice in Google Search Console. Google legge i file figli dall'indice, quindi non devi gestire a mano ogni file XML generato. Nelle installazioni multistore, ogni shop riceve il proprio indice e i propri file figli basati sull'ID shop.

Sì. Con il Product Canonical Manager imposti regole per entità su prodotti, categorie, produttori, fornitori e pagine CMS, e il modulo scrive le direttive noindex e/o nofollow selezionate nel meta tag robots della pagina. Lo stesso modulo rigenera i tag hreflang dalle lingue attive dello shop e aggiunge x-default per la lingua predefinita, così ogni versione lingua punta alle alternate corrette.

Questo tiene fuori dall'indice Google pagine con pochi contenuti o duplicate (listing filtrati, ricerca interna, pagine account) mentre i prodotti reali restano indicizzabili, e dice a Google quale lingua servire a quale pubblico. Un errore comune è aggiungere noindex e un canonical che puntano in direzioni diverse sullo stesso URL; decidi per pagina se vuoi indicizzarla ma canonicalizzarla, oppure tenerla completamente noindex, non entrambe le cose in conflitto.

La Smart SEO Revolution Suite condivide lo stesso motore canonical, hreflang e noindex, quindi le stesse regole per entità sono disponibili anche lì.

Le regole hanno priorità e scope shop. La ricerca delle regole accetta l'ID entità esatto o l'ID entità 0, e le regole esatte o globali shop possono essere ordinate per priorità. Questo ti permette di creare una regola ampia per tutti i prodotti, poi sovrascrivere un prodotto, una categoria o una pagina CMS importante senza duplicare ogni impostazione.

Il tag robots viene costruito solo dalle direttive che scegli. Se selezioni noindex, il modulo aggiunge noindex; se selezioni nofollow, aggiunge nofollow; se nessuna è selezionata, non inventa un tag robots solo per essere visibile. I tag robots esistenti vengono sostituiti quando una regola si applica, così eviti due meta robots conflittuali nello stesso head.

La generazione hreflang ha senso solo su shop multilingua. Il modulo controlla le lingue attive, genera URL alternate per ogni lingua attiva e aggiunge x-default per la lingua predefinita configurata. Rimuove anche i tag hreflang esistenti prima di inserire i propri, il che aiuta a evitare gruppi duplicati di versioni linguistiche alternative da tema e modulo che provano entrambi a possedere lo stesso segnale.

Usa noindex con attenzione rispetto alle sitemap. Un URL escluso dall'indicizzazione tramite noindex non dovrebbe essere promosso come URL sitemap indicizzabile, e le tabelle policy della SEO Suite includono override separati per index, hreflang, sitemap e schema proprio per questo. Mantieni i segnali allineati: pagine indicizzabili ricevono canonical e hreflang; pagine intenzionalmente nascoste ricevono noindex e normalmente restano fuori dalla sitemap XML.

Di solito dipende da alcune cose risolvibili, e la più comune è alt text mancante o vuoto. Google si appoggia molto all'attributo alt e al contesto circostante per capire cosa mostra un'immagine, quindi immagini senza alt descrittivo raramente emergono in Image search. Passa questa lista:

• Alt text vuoto o generico, il fattore principale; sistema questo per primo.
• robots.txt blocca la cartella immagini. Google non può indicizzare ciò che non può recuperare.
• Immagini caricate solo da JavaScript lazy-loading che il crawler non esegue (meno comune oggi con il lazy loading nativo).
• Nessuna voce immagine nella sitemap, quindi la scoperta è più lenta.
• Immagini molto piccole o di bassa qualità che Google può decidere di non indicizzare.

Inizia dall'alt text. Automatic SEO Images Alt Tags lo genera dai dati catalogo, nome prodotto, produttore, categoria, riferimento e altro, e può riempire solo le legend vuote o sostituire quelle esistenti. Nota che dà a Google alt text pulito da leggere; non garantisce indicizzazione o ranking.

Nel modulo, il template prodotto predefinito è {product_name} - {manufacturer}, le pagine listing usano {product_name} - {category}, le categorie usano {category_name}, e la lunghezza massima predefinita è 125 caratteri. Puoi aggiungere placeholder come {reference}, {ean13}, {mpn} e {image_position} per rendere più distinte le immagini gallery. Il builder rimuove separatori vuoti e taglia il testo lungo al confine di parola, così un template come {product_name} - {manufacturer} - {reference} resta leggibile anche quando manca un campo.

Il modulo riempie il valore legend/alt immagine al momento della presentazione per cover prodotto, immagini gallery prodotto, immagini listing e immagini categoria supportate. Di default riempie valori vuoti senza sovrascrivere legend scritte a mano; abilita la sostituzione solo dopo aver controllato che il tuo alt text manuale non sia migliore. Dopo aver cambiato i template, svuota la cache e ispeziona gli attributi img alt renderizzati su una pagina prodotto e categoria. Non è un generatore di sitemap immagini e non può costringere Google a indicizzare un'immagine, ma rimuove uno dei principali blocchi lato catalogo.

Sì. Il modulo registra i vecchi URL quando cambiano URL di prodotto/categoria/CMS/produttore/fornitore e serve redirect dalla tabella history. È esattamente pensato per proteggere URL Google indicizzati dopo cambi slug o pattern. Usa redirect 301 per spostamenti permanenti, mantieni attiva la cronologia redirect ed evita di cambiare pattern URL ripetutamente salvo tu sia pronto a gestire la catena di redirect.

La tabella history salva vecchio URL, nuovo URL, tipo redirect, tipo entità, ID entità, ID shop, flag attivo, hit count, data ultimo hit e motivo del cambio. Il lifecycle handler cattura vecchi URL prima degli update entità, li confronta dopo l'update e registra cambi URL per prodotti, categorie, pagine CMS, produttori e fornitori. Ha anche comportamento su delete e disable che può reindirizzare a un parent, homepage, 410 Gone o nulla, in base alla configurazione.

Al momento della richiesta, il router controlla override e voci history e restituisce l'URL redirect configurato e il tipo redirect quando viene abbinato un vecchio URL. Per migrazioni SEO, mantieni attive le vecchie righe history abbastanza a lungo perché motori di ricerca e link esterni si stabilizzino, preferisci 301 per cambi slug permanenti e testa URL indicizzati importanti con una richiesta HTTP diretta per confermare che restituiscano un solo redirect pulito alla destinazione finale.

Lo schema PrestaShop, chiamato anche structured data, è un piccolo livello extra di codice che dice ai motori di ricerca cosa rappresenta ogni parte del contenuto della pagina: un prezzo, uno stato stock, un prodotto, una valutazione, una breadcrumb trail o una voce FAQ. I motori di ricerca possono usare quei dati per funzioni rich result idonee come snippet prezzo e stock prodotto, stelle recensione dove supportate, link breadcrumb o presentazioni in stile FAQ dove il motore le supporta ancora.

I rich result non spingono da soli la tua pagina più in alto nel ranking, ma possono rendere il risultato più utile e più affidabile. Per uno store, i tipi schema che di solito contano sono Product, Offer, AggregateRating/Review, BreadcrumbList, Organization, WebSite, CollectionPage, Article e, dove appropriato, FAQPage.

Il nostro modulo Automatic SEO Schema Rich Snippets prova ad aggiungere markup Product, Offer, rating/review, breadcrumb, Organization, WebSite, categoria e pagina CMS senza modificare template. La stessa funzionalità schema fa anche parte della Smart SEO Revolution Suite se vuoi anche sitemap, canonical e automazione meta tag in un unico posto.

Avvertenza importante sul codice attuale: il modulo emette JSON-LD da hookDisplayHeader, ma clean_existing_jsonld è attivo di default e la pulizia dell'output finale preserva solo script JSON-LD contenenti il marker <!-- mprschema -->. L'hook header attualmente emette JSON-LD senza marker, quindi con la pulizia JSON-LD attiva l'HTML finale può rimuovere lo schema del modulo stesso. Finché il renderer non marca gli script o la logica di cleanup non viene disattivata/corretta, verifica il sorgente finale della pagina prima di considerare il JSON-LD presente in modo affidabile.

Sulle pagine prodotto, lo schema Product può includere nome prodotto, URL, descrizione, SKU, identificativi GTIN/UPC/ISBN/MPN, dati brand da produttore/fornitore/feature, immagini, item condition, dati offer, peso, categoria e dati recensione quando lo shop li possiede. Il generatore brand usa la fonte catalogo configurata, come produttore, fornitore o una feature chiamata Brand, con fallback al produttore; il campo override-brand dichiarato non è usato dal generatore attuale. I dati Offer possono includere prezzo, valuta, disponibilità, seller, dettagli spedizione e return policy. Per prodotti con combinazioni, l'implementazione può costruire dati aggregate offer invece di fingere che ogni variante abbia una singola offerta identica.

Le pagine categoria sono gestite diversamente: vengono renderizzate come dati CollectionPage con nome categoria, URL, descrizione, immagine, numero di articoli e un campione ItemList di prodotti. Le pagine CMS sono renderizzate come schema Article con headline, URL, descrizione, corpo articolo, conteggio parole, date, autore, publisher, logo, lingua e main entity URL.

La regola pratica per il merchant è compilare i dati di base, non solo attivare lo schema. Se un prodotto non ha identificativo, ha immagini deboli, nessuno stato stock, nessuna recensione o una descrizione vuota, lo schema può descrivere solo quei dati deboli. Structured data funziona meglio quando i dati catalogo sono già puliti, e nel modulo attuale dovresti anche controllare che le impostazioni di cleanup non rimuovano il JSON-LD che ti aspetti di pubblicare.

Siamo realisti: un modulo SEO mette in atto i segnali tecnici, dati strutturati, URL più puliti, tag canonical e linking interno, ma quando queste modifiche compaiono nei risultati di ricerca dipende da Google, non dal modulo. Google deve prima ri-scansionare e rielaborare le tue pagine, e questo tempo varia da negozio a negozio: per alcune pagine qualche giorno, per altre molto più a lungo, a seconda della frequenza con cui Google rivisita il tuo negozio. Nessuno può fissare una data precisa.

Alcune azioni accelerano i primi segnali: inviare una sitemap XML aggiornata, correggere i 404 e reindirizzare le vecchie URL così che il crawl budget arrivi sulle pagine che contano. Sono esattamente le leve gestite dalla nostra Smart SEO Revolution Suite. Ciò che nessun modulo può fare è garantire un posizionamento a una data precisa: chi promette risultati immediati ti sta ingannando. Gestiamo negozi anche noi, quindi siamo onesti: il SEO è una corsa di resistenza e un buon modulo accorcia la parte tecnica, non l'orologio di Google.

Esegui uno dei tuoi URL prodotto nel Rich Results Test di Google - mostra quali structured data Google trova sulla pagina e segnala errori o warning. Puoi anche monitorare la copertura nel tempo in Google Search Console sotto i report Enhancements. Dopo aver installato il nostro modulo Schema & Rich Snippets, testa alcune pagine prodotto, categoria e CMS prima di fidarti dell'output storefront.

Nel back office del modulo, la schermata preview ti permette di scegliere un tipo pagina e generare JSON-LD prima di affidarti alla pagina live. Product, Organization, WebSite, Breadcrumb, Category e CMS schema sono abilitati di default, mentre il markup FAQ è off di default perché il contenuto FAQ deve corrispondere al contenuto visibile della pagina. Lo schema Product usa dati catalogo come produttore/brand, identificativi stile SKU, condition, recensioni, varianti e fino a cinque immagini salvo tu cambi il limite immagini.

Avvertenza importante sul codice attuale: lo schema storefront live andrebbe verificato con cleanup JSON-LD esistente disattivato, oppure dopo che l'output del modulo è marcato in modo che il cleaner lo preservi. Il modulo emette script JSON-LD in displayHeader, ma lo step di cleanup gira sull'HTML finale e rimuove blocchi application/ld+json salvo contengano il marker comment del modulo. L'output header attuale non include quel marker, quindi il cleanup predefinito può rimuovere lo schema appena renderizzato dal modulo.

Questo significa che dovresti validare sia l'output preview sia l'URL pubblico reale dopo cache, hook del tema e altri moduli SEO. Se cleanup è attivo, controlla il sorgente reale della pagina per confermare che il JSON-LD sia ancora presente. Warning per campi opzionali non bloccano sempre l'idoneità, ma errori nei campi Product richiesti vanno corretti prima di aspettarti rich result. Anche uno schema valido non garantisce che Google mostri rich result; rende solo la pagina idonea.

In parte, e dipende dal motivo che Google indica accanto a ogni URL. Sii onesto con te stesso: nessun modulo può obbligare Google a indicizzare una pagina. Possiamo però risolvere le cause tecniche che Google segnala spesso.

• Rilevata/sottoposta a scansione, non indicizzata, o sitemap mancante: l'Advanced SEO Sitemap Builder genera una sitemap XML verificata e può avvisare Google e Bing a ogni modifica, così gli URL buoni sono facili da trovare.
• Duplicato / pagina alternativa con canonical: gestito dalle regole canonical e noindex della Smart SEO Revolution Suite, che gestisce anche i redirect 301/302 degli URL spostati.

Il resto è lavoro sui contenuti e sul server che il modulo non fa al posto tuo: pagine scarne, pagine giudicate di scarso valore da Google o errori del server. Apri in Search Console il motivo esatto per ogni URL, risolvi la causa e reinvia. Errore comune: tenere nella sitemap pagine impostate anche su noindex, il Sitemap Builder salta gli URL in noindex e non-200 per non inviare segnali contraddittori.