Integrazione

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.

Stefano Novelli · · 6 min di lettura ·Aggiornato il
Come integrare AnchorLabs in una testata: guida passo-passo in 10 minuti

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 il body

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.

<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 pagina
  • data-pt-max-matches-per-keyword: massimo numero di occorrenze per la stessa keyword
  • data-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:

  1. Apri DevTools e verifica che index.iife.js carichi con status 200.
  2. Controlla che nel DOM compaiano gli elementi decorati dal runtime.
  3. Passa il mouse o tocca una keyword: deve comparire un tooltip floating.
  4. 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 su body
  • 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 è:

  1. Network: lo script viene caricato e non è bloccato dal CSP.
  2. Tooltip: almeno una keyword valida viene decorata.
  3. Click: il click apre l'URL corretto.
  4. 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-selectors punta 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.it in script-src
  • https://anchor.widgetbay.3labs.it in connect-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.