SEO programmatico: come creare pagine su larga scala (senza fare spam)

TL;DR: Il programmatic SEO è un’unica template più un dataset strutturato che genera molte pagine ottimizzate per specifiche keyword. Funziona solo se ogni variazione ha una domanda reale di ricerca e ogni pagina offre un valore unico. Senza entrambe le cose, stai producendo pagine sottili che Google potrebbe classificare come scaled content abuse.

Domanda	Risposta “safe”	Segnale di allarme
Ogni query ha una domanda?	Hai evidenze che le persone cercano quella specifica variazione.	Hai generato tutte le combinazioni possibili perché i dati lo consentivano.
Ogni pagina è davvero diversa?	Cambia il dato di base, il risultato, l’inventario o l’utilità.	Cambia solo il nome di una città, di un’app, di una valuta o di una categoria.
Il formato rispecchia l’intento?	Calcolatori, tabelle, comparazioni o elenchi corrispondono a ciò che si posiziona.	Si usa un template generico di articolo per ogni tipo di query.
Il dato è “difendibile”?	È data proprietaria, concesso in licenza, fornito dagli utenti o data pubblica con un valore aggiunto.	Viene scraped e riscritto leggermente da pagine concorrenti.
Google può scoprire le pagine?	Le pagine collegano sibling rilevanti e hub di livello superiore (parent hubs).	Gli URL generati esistono solo in una sitemap XML.
Ogni variazione dovrebbe essere indicizzata?	Pubblicare solo combinazioni utili supportate dalla domanda.	Scaricare nel’/indicizzazione l’intero prodotto cartesiano.

Il programmatic SEO è un sistema di pubblicazione, non una strategia di contenuti

Ahrefs definisce il programmatic SEO come “la creazione di pagine targetizzate su keyword in modo automatico (o quasi automatico)”. Tradotto in termini da “costruzione”: colleghi un template di pagina a un foglio di calcolo, a un database o a un’API e compili riga dopo riga.

Il pattern delle query normalmente assomiglia a [head term] + [modifier]. L’elenco dei modifier diventa il dataset:

• converti [valuta A] in [valuta B]
• [App A] + [App B] integrazione
• salary [ruolo/job title] in [città]
• best [categoria] in [città]

Ricercare il pattern una volta, costruire il template una volta e generare centinaia o migliaia di URL targetizzati. Meccanicamente è semplice. Un dev può produrre 50.000 route prima di pranzo se nessuno si prende la tastiera (e sì, sono stato io la persona che aveva bisogno che gli togliessero la tastiera).

La domanda difficile è se quelle route meritano di diventare pagine indicizzabili.

In passato davo troppo credito alla “bellezza tecnica” del sistema. Google non vede lo schema pulito, la coda intelligente o il client API digitato con cura. Vede gli URL risultanti e valuta se aiutano la persona che è atterrata lì.

La linea di demarcazione: domanda e valore unico

Una pagina programmatica difendibile ha bisogno di due elementi simultaneamente:

1. Una domanda reale per la query specifica.
2. Un valore unico concreto nella pagina risultante.

Se manca anche solo una delle due condizioni, la scalabilità gioca contro di te.

La domanda deve esistere a livello di variazione

La domanda sull’head term non basta. Cercare “currency converter” non dimostra che ogni possibile coppia di valute meriti un URL indicizzabile.

Questa è keyword research a livello di pattern. Parti dalla forma di query ripetibile, poi valida i modifier rappresentativi sia sulla parte “head” sia sul long tail. Gli strumenti di volume non risolvono ogni variazione oscura, quindi combina le loro stime con i dati di Search Console, l’uso del prodotto, il linguaggio dei clienti e la composizione delle SERP.

Non pubblicare l’intero database di default.

Se una tabella contiene 200 entità, generare ogni coppia sembra sorprendentemente “completo”. La logica di prodotto ama le matrici complete. La domanda di ricerca però raramente si comporta in modo così ordinato (fastidioso, ma importante). Un dataset da 200 elementi può generare 39.800 coppie direzionali, ma solo una frazione potrebbe corrispondere a domande reali.

Definisci una regola di idoneità prima della generazione. Una pagina può richiedere una domanda misurabile, dati sottostanti sufficienti, un elemento di inventario attivo oppure una relazione prodotto già consolidata. Le righe che falliscono devono restare dati, non diventare URL.

Il dataset deve cambiare la risposta

Il template è solo la cornice. Il dataset deve produrre un risultato davvero significamente diverso per ogni URL.

Le pagine sulle valute di Wise sono un modello utile perché una coppia specifica può fornire il proprio tasso di cambio, la storia dei tassi e un calcolatore. Le pagine di coppie di app di Zapier possono descrivere e abilitare un collegamento reale tra due strumenti con nomi specifici. Le pagine “stile Tripadvisor” sulle località contengono inventario diverso, recensioni, disponibilità e prezzi.

Confrontale con 5.000 pagine località in cui l’unica modifica è:

“Cerchi il commercialista migliore in [città]? La nostra piattaforma aiuta le aziende in [città] a trovare commercialisti.”

Questa non è value locale. È trova-e-sostituisci.

Il test di valutazione che preferisco è il strip-the-variable test: prendi due pagine generate, rimuovi la città, la valuta, l’app o la categoria e confronta ciò che resta. Se le pagine collassano in una risposta praticamente identica, il valore unico è troppo sottile. Non esiste una percentuale pubblicata di “unicità” che renda un URL sicuro, però. È una decisione di prodotto, non una regola di “linter”.

Un test più forte è chiederti cosa andrebbe perso se la pagina sparisse. Se la risposta è semplicemente “un’altra strada verso la nostra pagina di iscrizione”, la pagina probabilmente esiste per l’acquisizione più che per l’utilità.

Google non si preoccupa di come sono state prodotte le pagine

John Mueller, Search Advocate di Google, ha descritto il problema di esecuzione in modo più diretto rispetto alla maggior parte delle guide SEO:

“Il programmatic SEO è spesso una insegna elegante per lo spam.”

Questa frase arriva da un post di Mueller stesso, non da un documento ufficiale di policy. È comunque un avvertimento utile: la tecnica è neutrale, ma l’implementazione comune spesso non lo è.

Google ha formalizzato la policy rilevante a marzo 2024. Le sue spam policies aggiornate hanno introdotto scaled content abuse e spostato l’attenzione da come viene realizzato il contenuto. Al momento dell’annuncio, Google ha detto che queste modifiche, combinate con i lavori precedenti, avrebbero dovuto ridurre del 40% i contenuti di bassa qualità e non originali nei risultati di ricerca. Era l’aspettativa dichiarata da Google, non un risultato misurato dopo il rollout.

L’aggiornamento core di accompagnamento è iniziato il 5 marzo 2024 e si è protratto per 45 giorni, concludendosi intorno al 19 aprile. L’update spam è iniziato lo stesso giorno ed è durato 14 giorni e 21 ore. La durata insolita del rollout core conta meno della policy rimasta dopo.

“Scaled content abuse è quando molte pagine vengono generate con lo scopo principale di manipolare i ranking di ricerca e non aiutare gli utenti.”

Le spam policies di Google Search Central includono esplicitamente l’uso di AI generativa per produrre molte pagine senza aggiungere valore e lo scraping di feed, risultati di ricerca o altro contenuto per generare pagine in cui viene fornito poco valore.

La policy è agnostica rispetto al metodo. AI, template, automazione e writer umani possono tutti creare pagine utili. Possono anche creare spam. Un passaggio di approvazione umana non salva una pagina che continua a non aggiungere nulla.

Google afferma anche: “I siti che violano le nostre policy possono posizionarsi più in basso nei risultati oppure non comparire affatto.” Usalo come modello del rischio. Il programmatic SEO a basso valore non è necessariamente un esperimento isolato; pubblicarlo sul dominio principale può esporre l’intero sito.

Doorway abuse è la seconda trappola

Progetti scadenti di pagine località possono anche sconfinare nel doorway abuse. Google definisce doorway abuse come pagine “create per posizionarsi su query di ricerca specifiche e simili” che portano gli utenti a pagine intermedie meno utili rispetto alla destinazione finale.

Un esempio familiare è una serie di pagine di città quasi identiche che convogliano tutti i visitatori verso la stessa pagina di servizio generica. L’URL promette qualcosa di specifico per Bristol, Amburgo o Praga. La pagina non offre inventario locale, evidenze locali, disponibilità, prezzi o differenze operative.

L’automazione in sé non è il problema. Io automatizzerei volentieri un milione di risultati davvero utili. Non pubblicherei 1.000 pagine boilerplate perché il numero più piccolo sembra meno sospetto. Google non fornisce un conteggio “sicuro” di pagine.

Un workflow pratico di programmatic SEO

1. Trova un pattern di query finito e ripetibile

Parti da un head term e da un set di modifier limitato. Città, valute, nomi di app, categorie di prodotto, job title e integrazioni tecniche funzionano perché le entità possono essere strutturate.

Non iniziare con “Come facciamo a generare 10.000 pagine?”. Inizia con “Quali domande ripetute può rispondere meglio il nostro dataset rispetto a una singola pagina generica?”. La seconda domanda potrebbe produrre solo 600 URL idonei. Va bene. Il numero di pagine è un output, non un obiettivo.

Crea una tabella candidata con query, modifier, intento atteso, campi unici disponibili, frequenza di aggiornamento e stato di pubblicazione. Dai a ogni riga un risultato di idoneità esplicito. Questo rende anche la potatura reversibile: una riga soppressa può diventare pubblicabile più avanti se la domanda o i dati migliorano.

2. Verifica l’intento su query rappresentative

Controlla le variazioni popolari, quelle di fascia media e quelle poco cercate. Se le pagine che si posizionano sono calcolatori, costruisci un calcolatore. Se sono tabelle di confronto, un articolo generico da 1.500 parole probabilmente è la UI sbagliata. Se i risultati dipendono da inventario live, una prosa statica non può soddisfare lo stesso bisogno.

Non fidarti di un singolo esempio di pagina risultati. Un pattern può rompersi. “Software per dentisti” e “software per sviluppatori” condividono un template grammaticale, ma possono richiedere evidenze diverse, filtri diversi, feature di prodotto diverse e criteri d’acquisto diversi. Il tuo sistema deve ottenere il permesso di non generare una pagina.

Registra queste classi di intento nel data model. Un singolo pattern di query potrebbe richiedere due o tre template invece di un “guscio” infinitamente flessibile.

3. Metti in sicurezza i dati prima di progettare il template

I dati proprietari sono la base più solida perché i competitor non possono replicarli copiando la struttura del tuo URL. Dataset pubblici o con licenza possono funzionare lo stesso se aggiungi calcoli, filtering, comparazioni, storia, normalizzazione o una UI migliore.

Fare scraping delle pagine concorrenti e “sinonimizzare” il loro testo è l’opposto della difendibilità. È anche citato esplicitamente negli esempi di scaled content abuse di Google.

Pianifica i campi mancanti e quelli obsoleti. Se una pagina ha bisogno di un prezzo, una misura, una connessione o un record di inventario per essere utile, una riga vuota non dovrebbe “scivolare” in silenzio su quattro paragrafi boilerplate. Sopprimi la pagina, restituisci uno stato appropriato oppure consolidala in una pagina parent utile finché non esiste il valore richiesto.

4. Costruisci una pagina completa, non un guscio flessibile

Mappa title, heading principale, descrizione, schema, moduli del body, navigazione e link correlati su campi espliciti. Poi fai passare una pagina rappresentativa attraverso design, rendering, QA e controlli di indicizzazione prima di abilitare la generazione in bulk.

Testa prima i record “scomodi”: nomi lunghi, campi opzionali mancanti, zero risultati, set di caratteri insoliti, etichette sovrapposte, timestamp obsoleti ed entità senza sibling correlati. La riga del “happy path” fa sembrare finito ogni template.

La coerenza conta, ma coerenza non significa identicità. Titoli ed elementi strutturali possono seguire regole. La risposta, i dati, l’utilità, gli esempi e le relazioni devono cambiare con la query.

5. Genera il grafo di internal link usando le pagine

Gli URL generati non hanno automaticamente un posto significativo nella tua architettura. Una sitemap può renderli visibili ai crawler, ma non può spiegare che relazione hanno con il resto del sito.

Normalmente voglio tre livelli di link:

• Hub links: ogni pagina detail confluisce in una categoria o in un hub tematico utile.
• Sibling links: le pagine collegano variazioni davvero correlate.
• Contextual links: le pagine editoriali rimandano a risultati programmatici rilevanti.

Una pagina USD-to-EUR può linkare verso l’alto a un hub di valute e lateralmente verso coppie USD o EUR pertinenti. Una pagina di integrazione può linkare sia agli hub delle app sia a workflow adiacenti che risolvono un compito simile.

Questo è una forma scalabile di content silo architecture. Memorizza le relazioni nel tuo data model invece di aggiungere, dopo il lancio, un widget “related pages”.

Da ciò che vediamo su siti che usano SEOJuice, le sitemap-only inventories sono un punto debole ricorrente. Le pagine generate che ricevono hub, sibling e link contestuali utili hanno un percorso molto più chiaro dentro il sito rispetto alle pagine lasciate “galleggiare” dietro una sola entry in sitemap. È esperienza qualitativa dell’operatore, non una promessa che aggiungere cinque link obblighi l’indicizzazione.

6. Controlla crawl e indicizzazione

Una sitemap XML pulita supporta la scoperta, ma non rende le pagine deboli meritevoli di essere indicizzate. Google potrebbe scegliere di non eseguire crawl o indicizzare ogni URL generato.

Monitora Search Console per “Discovered – currently not indexed” e “Crawled – currently not indexed.” Cluster grandi in quello stato meritano un’indagine su template e classe di pagina, non panico URL-per-URL. Verifica domanda, duplicazione, internal link, rendering, regole canonical, completezza dei dati e performance del server.

La prima volta che ho visto migliaia di URL generati rimanere fuori dall’indice, ho pensato ci fosse un bug tecnico. Ce n’era uno, ma sistemarlo non ha risolto il problema di indicizzazione. Le pagine rimaste semplicemente non offrivano abbastanza valore.

Elimina le combinazioni senza domanda, gli stati duplicati, le listings vuote, le varianti facettate e le pagine che non riescono a fornire l’utilità promessa. La nostra guida su crawl budget optimization copre la parte meccanica del controllo di un grande inventario URL.

Preferisco rilasci “a step” rispetto a un’unica grande partenza. È una preferenza operativa, non un requisito di Google. Batch più piccoli rendono più facile individuare tag canonical rotti, classi di pagina sottili, link scadenti e dati mancanti prima che questi si moltiplichino.

In comune con i siti programmatic che funzionano

Le stime snapshot di Ahrefs mostrano quanto possono diventare grandi le implementazioni utili:

Sito	Stima di Ahrefs della scala	Valore per pagina
Zapier	Circa 800.000 pagine	Un collegamento utilizzabile tra una specifica coppia di app
Wise	Circa 14.900 pagine	Tassi, storia e utilità di conversione per una coppia di valute
Nomadlist	Circa 25.000 pagine città	Dati città standardizzati come costi, internet, meteo e sicurezza
Webflow	Circa 31.000 pagine tra template e showcase	Design distinti creati dagli utenti

Sono stime di Ahrefs, non conteggi live permanenti. Tenderanno a variare, e confrontare il tuo inventario pianificato con il numero di pagine di Zapier non è particolarmente utile.

Il vantaggio condiviso è che il dataset differenzia le pagine. Zapier è un forte esempio di SEO per SaaS perché ogni pagina generata valida mappa una capability di prodotto. Il risultato di Wise cambia con la coppia di valute. Il record città di Nomadlist contiene misurazioni specifiche della città. Le pagine di Webflow mostrano lavori distinti creati dagli utenti.

In questi esempi, la scalabilità segue il valore. Non lo sostituisce.

Modalità di fallimento che bloccherei prima del lancio

• Pagine sottili: la maggior parte della pagina visibile è copia del template con poche informazioni specifiche della query.
• Quasi duplicati: rimuovendo la variabile iniettata, più pagine diventano di fatto identiche.
• Combinazioni senza domanda: ogni combinazione possibile del dataset viene generata senza evidenza che qualcuno la cerchi davvero.
• Contenuti scraped o “sinonimizzati”: i competitor forniscono la sostanza mentre l’automazione la camuffa soltanto.
• Pagine con risultato vuoto: l’URL promette inventario, dati o un risultato che la pagina non può fornire.
• Inflazione nell’indicizzazione: migliaia di URL vengono lanciati senza regole di idoneità, potature o relazioni interne utili.

Questi sistemi possono sembrare impressionanti internamente. Lavoro completato. La sitemap contiene 50.000 URL. Il grafico del deployment è salito. Ma nulla di tutto questo dimostra che le pagine siano utili, scoperte o indicizzate.

Qui il conteggio delle pagine è una metrica “vanity”. Le pagine supportate dalla domanda che soddisfano le loro query specifiche sono l’asset.

Dove si inserisce SEOJuice e dove no

SEOJuice non genera set di pagine programmatic. Non deciderà quali coppie di valute meritano pagine, non inventerà dati proprietari e non “salverà” un template sottile.

Il suo ruolo inizia dopo che esistono pagine utili. SEOJuice punta a un sito live e applica continuamente internal link contestuali, meta title e meta description, markup schema e testo alternativo (alt-text) delle immagini. Su un grande inventario generato, questi task diventano ripetitivi e sorprendenti anche a livello di incoerenza, molto rapidamente, soprattutto per un team di due persone come il nostro.

Il fit migliore è l’internal linking. Il sistema può aiutare a collegare in modo contestuale le pagine generate live, mentre l’automazione più ampia mantiene completi gli elementi ricorrenti on-page. Le regole di idoneità, la qualità del dataset, il template, la logica canonical e la decisione di indicizzare ogni classe di pagina restano comunque di tua proprietà.

Se mantenere l’inventario generato sta diventando il collo di bottiglia, SEOJuice ha un piano free senza carta di credito. Se invece il problema iniziale è trovare i modifier candidati, prova il nostro AI keyword extractor e tratta l’output come un seme di ricerca, non come autorizzazione a pubblicare ogni frase che trova.

Domande frequenti

Cos’è il programmatic SEO?

Il programmatic SEO è la creazione di molte pagine targetizzate su keyword a partire da un unico template e da un dataset strutturato, come un foglio di calcolo, un database o un’API. Il template viene compilato riga per riga per intercettare pattern di query ripetibili come “converti [valuta A] in [valuta B]”.

Il programmatic SEO è contrario alle linee guida di Google?

No. Il metodo di produzione in sé non è vietato. La policy di Google sul scaled content abuse mira a pagine generate principalmente per manipolare i ranking invece di aiutare gli utenti. L’automazione utile è diversa dal produrre, su larga scala, pagine sottili e quasi duplicati.

Il programmatic SEO può farmi deindicizzare il sito?

Sì, se fatto male il programmatic SEO può creare un rischio a livello di sito. Google afferma che i siti che violano le sue spam policies possono posizionarsi più in basso o non comparire affatto nei risultati. Evita di trattare le pagine generate a basso valore come un esperimento innocuo su un dominio altrimenti valido.

Cosa rende una pagina programmatica sottile o “spammy”?

Usa il strip-the-variable test. Se rimuovere la città, la valuta, l’app o la categoria rende due pagine quasi identiche, allora sono per lo più boilerplate. Contenuti scraped, risultati vuoti e pagine create per query senza una domanda reale sono ulteriori segnali di allarme.

Quali sono buoni esempi di programmatic SEO?

Esempi comuni includono le pagine di integrazione tra app di Zapier, le pagine di conversione valute di Wise, le pagine città di Nomadlist e grandi marketplace di viaggio con inventario basato sulle località. Ognuno combina un pattern di query ripetibile con dati o utilità che cambiano in modo sostanziale in ogni pagina.

Quante pagine posso pubblicare in modo programmatico in sicurezza?

Google non fornisce un numero fisso “sicuro”. Il limite pratico è il numero di variazioni di query con domanda reale per cui riesci a fornire un valore unico. Diecimila pagine utili potrebbero essere difendibili; una collezione molto più piccola di quasi duplicati potrebbe comunque violare le policy di Google.