Come integrare AnchorLabs in una testata: guida passo-passo in 10 minuti
Tutorial completo per installare AnchorLabs sul tuo sito editoriale con lo snippet reale della landing page: script async, data attributes, selettori opzionali, verifica e troubleshooting.
Hai un sito editoriale, un archivio pieno di articoli che citano prodotti nel testo e nessuna intenzione di tornare a editare a mano migliaia di pezzi per aggiungere link affiliati. AnchorLabs serve esattamente a questo: carica un runtime leggero, scansiona il contenuto già pubblicato, riconosce le keyword prodotto e le trasforma in tooltip cliccabili.
Questa guida è allineata all'installazione reale mostrata nella landing page di AnchorLabs. Quindi niente window.AnchorLabsConfig, niente runtime.js, niente configurazioni inventate: qui usiamo il file giusto (index.iife.js) e gli attributi data-pt-* che il prodotto supporta davvero oggi.
Prerequisiti
Prima di iniziare ti servono:
- Accesso al template o al tag manager del sito, cioè il punto in cui inseriresti anche uno script analytics o un pixel.
- Il tuo tag Amazon Associates, perché la landing generator lo tratta come parametro operativo obbligatorio del setup standard.
- Possibilità di fare deploy o pubblicare la modifica del tema/layout.
- Opzionale: il selettore del corpo articolo, se vuoi limitare la scansione a una parte precisa della pagina invece di usare il fallback su
body.
Se vuoi fare una prova veloce, puoi partire anche senza selettori: il runtime userà body.
Step 1: copia lo snippet reale della landing
L'installazione standard di AnchorLabs parte da questo formato:
<script
async
src="https://anchor.widgetbay.3labs.it/index.iife.js"
data-pt-auto-init="true"
data-pt-amazon-tag="tuotag-21"
></script>
Questo è il punto chiave da fissare subito:
- il file corretto è
index.iife.js - il bootstrap standard passa tramite
data-pt-auto-init="true" - la configurazione avviene sugli attributi del tag
<script> - se non imposti
data-pt-selectors, AnchorLabs scansiona ilbody
Quindi la versione minima dello snippet non richiede nessun blocco JS inline separato. È il contrario di quanto riportato in alcune guide vecchie.
Step 2: decidi se partire da body o restringere il perimetro
Con la logica attuale hai due modalità corrette.
Modalità 1: nessun selettore, scansione dal body
È la via più semplice per una prima installazione o per un sito con layout lineare.
<script
async
src="https://anchor.widgetbay.3labs.it/index.iife.js"
data-pt-auto-init="true"
data-pt-amazon-tag="tuotag-21"
></script>
Vantaggi:
- snippet minimo
- test rapido
- nessuna attività preliminare su DevTools
Svantaggio: se il sito ha sidebar, homepage dense, box correlati o template molto rumorosi, il body può essere più largo del necessario.
Modalità 2: selettori espliciti, scansione più stretta
Se vuoi agire solo sul corpo articolo, aggiungi data-pt-selectors:
<script
async
src="https://anchor.widgetbay.3labs.it/index.iife.js"
data-pt-auto-init="true"
data-pt-selectors=".entry-content,.post-content,.article-body"
data-pt-amazon-tag="tuotag-21"
></script>
Usa questa modalità quando vuoi:
- evitare nav, footer, sidebar e box commerciali secondari
- limitare la scansione alle sole pagine articolo
- tenere più controllo sul perimetro operativo
Regola pratica: per la prova iniziale puoi partire da body; per la messa in produzione su layout complessi conviene quasi sempre aggiungere selettori espliciti.
Step 3: inserisci lo snippet nel punto giusto
La posizione più semplice è nel template condiviso delle pagine che vuoi monetizzare, di solito nel footer o comunque prima della chiusura del </body>.
Esempi tipici:
- WordPress: plugin di header/footer injection,
wp_footer, oppure child theme. - Tag Manager: custom HTML tag sulle pagine articolo.
- Template server-side: layout base del sito o partial condivisa.
- Frontend custom: il punto in cui già inserisci script terzi.
Su stack come Next.js o altri framework puoi montare lo stesso snippet tramite il componente script del framework, ma gli attributi devono restare quelli reali della landing. Se cerchi una guida specifica per piattaforma, vedi anche AnchorLabs su WordPress e AnchorLabs su Next.js.
Step 4: aggiungi i parametri davvero supportati
Lo snippet può restare minimale, ma ci sono alcuni attributi utili che il prodotto supporta realmente.
Densità dei link
<script
async
src="https://anchor.widgetbay.3labs.it/index.iife.js"
data-pt-auto-init="true"
data-pt-amazon-tag="tuotag-21"
data-pt-max-total-matches="24"
data-pt-max-matches-per-keyword="1"
data-pt-max-matches-per-paragraph="2"
></script>
Servono a evitare overlinking:
data-pt-max-total-matches: massimo numero di tooltip nella paginadata-pt-max-matches-per-keyword: massimo numero di occorrenze per la stessa keyworddata-pt-max-matches-per-paragraph: massimo per singolo paragrafo, lista o blockquote
Parametri utili da impostare subito
Per una configurazione iniziale servono soprattutto questi tre:
<script
async
src="https://anchor.widgetbay.3labs.it/index.iife.js"
data-pt-auto-init="true"
data-pt-amazon-tag="tuotag-21"
data-pt-max-total-matches="24"
data-pt-max-matches-per-keyword="1"
data-pt-max-matches-per-paragraph="2"
></script>
Gli altri attributi esistono, ma vanno documentati bene e usati solo quando servono davvero. Per una guida di installazione iniziale non sono necessari.
Step 5: verifica che il runtime stia lavorando davvero
Dopo il deploy, apri una pagina del sito e fai questi controlli:
- Apri DevTools e verifica che
index.iife.jscarichi con status200. - Controlla che nel DOM compaiano gli elementi decorati dal runtime.
- Passa il mouse o tocca una keyword: deve comparire un tooltip floating.
- Clicca il link: deve aprirsi secondo la configurazione definita.
Se vuoi capire se il problema è lo scope, fai questo test semplice:
- prima prova senza
data-pt-selectors, quindi con fallback subody - se così funziona, ma con i tuoi selettori no, il problema è nei selettori
Questo test ti isola subito la causa più comune.
Step 6: verifica performance e raccolta eventi
Il runtime standard della landing è stato pensato per avere impatto operativo basso:
- script
async - bootstrap automatico dopo il DOM
- scheduling in idle
- tooltip floating, quindi senza spostare il testo
La verifica minima post-installazione è:
- Network: lo script viene caricato e non è bloccato dal CSP.
- Tooltip: almeno una keyword valida viene decorata.
- Click: il click apre l'URL corretto.
- Performance: la pagina non introduce CLS e non mostra long task anomali dovuti al runtime.
Per una trattazione più ampia sull'impatto dei widget di monetizzazione sulle performance editoriali, vedi Affiliate link e Core Web Vitals.
Troubleshooting
Problema 1: non compare nulla
Le cause più probabili sono:
- il contenuto non contiene keyword coperte dalle regole disponibili
data-pt-selectorspunta al nodo sbagliato- il CSP sta bloccando script o chiamate API
Test rapido: rimuovi temporaneamente data-pt-selectors. Se il runtime inizia a decorare dal body, il problema è nel selettore.
Problema 2: la scansione è troppo ampia
Se vedi match in zone che non vuoi monetizzare, non devi cambiare runtime: basta aggiungere data-pt-selectors e restringere il perimetro al corpo editoriale.
Esempio:
data-pt-selectors=".entry-content,.post-content"
Problema 3: lo script è bloccato dalla CSP
Se in console vedi errori tipo Refused to load script, devi consentire almeno:
https://anchor.widgetbay.3labs.itinscript-srchttps://anchor.widgetbay.3labs.itinconnect-src
Se i tooltip mostrano immagini prodotto, può servirti anche l'allowlist su img-src.
Problema 4: sei in staging e il tenant non viene risolto bene
Il setup standard usa il dominio della pagina corrente. Se stai testando su un host tecnico, aggiungi esplicitamente:
data-pt-tenant-id="dominio-produzione.it"
Cosa cambia davvero rispetto alla vecchia documentazione
Per evitare ambiguità, fissiamo i punti corretti una volta per tutte:
- non serve
window.AnchorLabsConfig - non devi caricare
runtime.js - lo snippet reale usa
index.iife.js - la configurazione standard passa tramite attributi
data-pt-* data-pt-selectorsè opzionale- se ometti i selettori, AnchorLabs usa
body
Questo è il comportamento vero del runtime attuale.
Conclusione
L'integrazione standard di AnchorLabs oggi è più semplice di quanto lasciassero intendere le guide vecchie: un solo script, un tag Amazon, e facoltativamente un selettore se vuoi restringere il perimetro. Se non lo metti, il fallback è body; se vuoi più controllo, aggiungi data-pt-selectors.
Per partire rapidamente, genera lo snippet dalla landing, fai un test iniziale senza selettore se vuoi validare il comportamento globale, poi restringi lo scope al corpo articolo quando passi alla configurazione definitiva.
Se stai valutando un setup più specifico per piattaforma, continua con:
Domande frequenti
L'integrazione di AnchorLabs richiede modifiche al CMS?
No. L'integrazione standard usa un solo tag <script> con attributi data-pt-* e non richiede plugin, modifiche al database o interventi redazionali.
Cosa succede se non imposto data-pt-selectors?
AnchorLabs usa body come root di scansione. È utile per una prima prova rapida o per layout molto semplici. Se vuoi limitare la scansione al solo corpo articolo, aggiungi data-pt-selectors con uno o più selettori CSS.
L'integrazione ha impatto sui Core Web Vitals della testata?
No, se installata come previsto dalla landing: script async, bootstrap automatico post-DOM e avvio in idle. Il runtime non blocca il rendering e i tooltip sono floating, quindi non introducono layout shift.