Case Study Technical SEO: il mio CV semantico e dinamico con GTM

Il fattore E-E-A-T

In questo articolo vi racconto il “dietro le quinte” tecnico di come ho costruito, iterazione dopo iterazione, uno script GTM personalizzato per automatizzare la mia EEAT.

1. La sfida del rendering: innerText vs textContent

La prima barriera è stata tecnica. Il mio sito utilizza il tema Avada, che fa ampio uso di animazioni e lazy loading degli elementi.
Il problema: La prima versione dello script tentava di leggere i titoli delle aziende usando la proprietà JavaScript .innerText. Il risultato? Un array vuoto. GTM scattava al caricamento del DOM, ma in quel millesimo di secondo, i titoli H4 erano tecnicamente “invisibili” (CSS opacity: 0 o visibility: hidden) in attesa dell’animazione di entrata. Per il browser, il testo non c’era.
La soluzione: Ho riscritto il parser utilizzando .textContent. A differenza di innerText, questa proprietà legge il contenuto grezzo del nodo nel codice sorgente, ignorando completamente lo stile CSS. Risultato: i dati sono apparsi magicamente, bypassando il rendering visivo.

2. Da lista piatta a database relazionale

Inizialmente, lo script raccoglieva tutto in un unico calderone knowsAbout. Ma dire a Google che “conosco” un’azienda non è semanticamente corretto. Io ho collaborato con quelle aziende.
L’evoluzione: Ho implementato una logica che distingue due proprietà fondamentali di Schema.org:

• knowsAbout: Per le competenze tecniche (SEO, Google Ads, ecc.)
• affiliation (o worksFor): Per le aziende e le agenzie partner.

Lo script ora scansiona la pagina, identifica i tag <h4> come “Entità Azienda” e li inietta nella proprietà corretta.

3. La gestione del caos: “Progetti minori”

Non tutti i blocchi del sito sono uguali. Mentre i grandi clienti hanno un blocco dedicato (es. “Valnan”), ho una sezione chiamata “Progetti minori” che è una lunga lista non strutturata, tipo:

• “Sito web e SEO su Seracom”
• “Consulenza Google ADS per L’Artemisia DB”

Se avessi passato queste stringhe grezze a Google, avrei sporcato il Knowledge Graph.
La soluzione “Ibrida”: Ho inserito nello script una funzione di pulizia (Data Cleaning). Quando lo script incontra il titolo “Progetti minori”, cambia modalità: invece di prendere il titolo, entra nella lista, legge ogni riga e – tramite un array di trash-words – rimuove frasi come “Sito web su…”, “Realizzazione…”, lasciando solo il nome pulito del brand (es. “Seracom”, “L’Artemisia DB”).

4. Precisione chirurgica con Wikidata

L’ultimo passaggio è stato trasformare le parole in concetti universali. Scrivere “Webmaster” è ambiguo. Collegare la parola all’identificativo Wikidata Q41674 è inequivocabile.
Ho arricchito l’array delle competenze statiche (knowsAbout) collegando ogni mia skill al suo corrispettivo nel database di Wikidata e Wikipedia:

• Web Design → Q190637 (Disciplina)
• Google Tag Manager → Q11775280
• Google Ads → Q271982

Inoltre, ho definito le competenze linguistiche usando la proprietà knowsLanguage, specificando il livello (C1 per l’inglese, Madrelingua per l’italiano) nel name per garantire che l’informazione fosse letta correttamente.

Risultato finale

Oggi, ogni volta che aggiorno il testo della pagina Curriculum su WordPress, Google Tag Manager:

1. Legge il nuovo HTML.
2. Pulisce i dati da prefissi inutili e anni.
3. Scarta i titoli di sezione (tramite una blacklist interna).
4. Genera un JSON-LD dinamico che descrive la mia entità Person con una precisione che nessun plugin standard potrebbe mai offrire.

Questo è il vero valore della Technical SEO: non subire la tecnologia, ma piegarla esattamente alle esigenze del business.