OpenTelemetry per la SEO

TL;DR — OpenTelemetry è uno strumento che gli ingegneri del software usano per vedere perché un sito web è lento — traccia una richiesta mentre si muove attraverso i tuoi server. Non è uno strumento SEO e non è un fattore di posizionamento. Poiché però pagine lente e Core Web Vitals scadenti possono incidere sul posizionamento, può aiutare un team tecnico a trovare la causa effettiva di un problema di velocità. Per la maggior parte dei siti è qualcosa che gli sviluppatori potrebbero avere già configurato, non un progetto da avviare nel fine settimana.

Cos’è OpenTelemetry

OpenTelemetry è un framework di osservabilità indipendente dal fornitore per produrre ed esportare telemetria sotto forma di tracce, metriche e log. Evidence for this claim OpenTelemetry is a vendor-neutral observability framework for traces, metrics, and logs; traces are composed of spans. Scope: OpenTelemetry concepts and data model, not an SEO-specific measurement standard. Confidence: high · Verified: 2026-07-14 OpenTelemetry: What is OpenTelemetry? Applicare questa telemetria alla diagnostica SEO è una metodologia ingegneristica, non un prodotto SEO definito da OpenTelemetry. Evidence for this claim Using OpenTelemetry to investigate crawl delivery or rendering is an editorial engineering methodology, not a feature defined by the OpenTelemetry project. Scope: Inference from general observability capabilities; OpenTelemetry does not directly report rankings or Search Console metrics. Confidence: medium · Verified: 2026-07-14 OpenTelemetry: Signals

OpenTelemetry (spesso abbreviato in OTel) è un framework open source che gli ingegneri del software usano per l’osservabilità, cioè per capire che cosa stanno facendo davvero i sistemi. Raccoglie tre tipi di dati: tracce (la storia di una richiesta), metriche (numeri nel tempo) e log.

La parte importante per te: è uno strumento di ingegneria, non uno strumento per motori di ricerca. Nessuno a Google o Bing lo ha inventato per la SEO, e non ha nulla a che fare con come un motore di ricerca classifica le tue pagine. È una tecnologia generica usata dai grandi team di sviluppo che può rivelarsi utile anche per un problema legato alla SEO: capire perché una pagina è lenta.

Perché un SEO potrebbe sentirne parlare

La velocità della pagina conta per la SEO. I Core Web Vitals di Google — un insieme di misurazioni di velocità e stabilità — fanno parte di come Google giudica l’esperienza della pagina. Se le tue pagine sono lente, questo può essere un problema.

Ecco il punto: i soliti strumenti SEO di velocità (PageSpeed Insights, Lighthouse) ti dicono che una pagina è lenta, ma non sempre perché. Su un sito web grande e complicato — molti server, JavaScript, script di terze parti — la vera causa può essere sepolta in profondità nel backend. OpenTelemetry è il modo in cui un team di ingegneria guarda dentro una richiesta per trovare la parte lenta.

Pensa a una traccia come a una ricevuta del caricamento di una pagina, con ogni passaggio e il tempo impiegato. Se un passaggio, come l’interrogazione del database, ha richiesto 3 secondi, la traccia te lo mostra. Questo è tutto il suo fascino.

È qualcosa che devi fare?

Probabilmente non direttamente, e va bene così. Per un sito piccolo — un negozio su Shopify, un blog su WordPress — è eccessivo. Non hai server da strumentare e strumenti più semplici troveranno qualsiasi problema di velocità tu abbia.

Dove conta davvero: siti grandi o ricchi di JavaScript nei quali il team tecnico sta già usando strumenti di osservabilità per l’app stessa. Se questo è il tuo mondo, la scelta giusta non è installare nulla, ma parlarne con gli sviluppatori: “Quando i Core Web Vitals sono scadenti su queste pagine, possiamo usare la nostra traccia per vedere dove va realmente il tempo?”

Il verdetto onesto

• Non è un fattore di posizionamento.
• Non è un sostituto di Google Search Console o Bing Webmaster Tools — quelli mostrano come il motore di ricerca vede il tuo sito; OpenTelemetry mostra come si comportano i tuoi stessi server.
• Google e Bing non lo hanno mai raccomandato per la SEO. Chiunque lo venda come “strumento SEO approvato da Google” se lo sta inventando.
• È un’idea emergente presa in prestito dall’ingegneria del software. Vale la pena conoscerla; non è qualcosa che la maggior parte dei SEO fa.

Vuoi la versione completa — tracce e span, il modello di correlazione tra frontend e backend, come si differenzia dall’analisi dei file di log, e chi dovrebbe davvero preoccuparsene? Passa alla scheda Avanzate.

TL;DR — OpenTelemetry è un framework di osservabilità open source e indipendente dal fornitore, sviluppato nella CNCF, che standardizza tracce, metriche e log. Non è uno strumento SEO né un fattore di posizionamento, e Google e Bing non lo hanno mai raccomandato per la SEO. Il caso d’uso pertinente consiste nel correlare i Core Web Vitals del frontend con le tracce del backend per individuare l’origine di un problema di velocità: inserisci un ID di traccia nella risposta, associalo ai dati web-vitals e verifica se un LCP elevato corrisponde a uno span lento nel backend o a un problema esclusivamente nel frontend. Il metodo integra l’analisi dei file di log: i log descrivono il comportamento di scansione, mentre le tracce spiegano la causa delle prestazioni. È realistico soprattutto per siti grandi o fortemente basati su JavaScript che dispongono già di osservabilità tecnica. Si tratta ancora di un approccio emergente, non di un’adozione documentata nel settore SEO.

Lascia che chiarisca le aspettative

OpenTelemetry può mostrare il comportamento delle richieste e dell’applicazione, ma non riporta direttamente le posizioni né sostituisce Search Console. Evidence for this claim Using OpenTelemetry to investigate crawl delivery or rendering is an editorial engineering methodology, not a feature defined by the OpenTelemetry project. Scope: Inference from general observability capabilities; OpenTelemetry does not directly report rankings or Search Console metrics. Confidence: medium · Verified: 2026-07-14 OpenTelemetry: Signals Il suo modello rappresenta il lavoro come tracce composte da span con attributi temporali e contestuali. Evidence for this claim OpenTelemetry is a vendor-neutral observability framework for traces, metrics, and logs; traces are composed of spans. Scope: OpenTelemetry concepts and data model, not an SEO-specific measurement standard. Confidence: high · Verified: 2026-07-14 OpenTelemetry: What is OpenTelemetry?

Voglio essere chiaro, perché su questo argomento è facile costruire una storia più convincente dei fatti. Non esiste alcuna guida ufficiale di Google o Bing che colleghi OpenTelemetry alla SEO. Le principali pubblicazioni del settore — Search Engine Land, Search Engine Journal e Search Engine Roundtable — non ne hanno parlato. Il materiale disponibile proviene quasi interamente dai blog dei fornitori di sistemi di osservabilità e da professionisti che descrivono la strumentazione dei Core Web Vitals: contenuti tecnici validi, ma rivolti ai responsabili dell’affidabilità dei sistemi, non ai SEO. Nessuna di queste fonti tratta la scansione, l’indicizzazione o il carico di rendering nel modo affrontato qui.

Questo articolo serve quindi da ponte: presenta uno strumento tecnico reale, individua l’unico ambito in cui i suoi dati si sovrappongono davvero alla SEO tecnica e chiarisce quando vale la pena occuparsene. Non lo descriverò come una tattica diffusa sostenuta da casi di studio e statistiche di adozione, perché tali prove non esistono ancora.

Cos’è realmente OpenTelemetry

OpenTelemetry è un progetto della Cloud Native Computing Foundation (CNCF), nato dalla fusione nel 2019 di OpenTracing e OpenCensus, che standardizza il modo in cui il software genera ed esporta telemetria: tracce, metriche e log. La definizione ufficiale lo descrive come un framework e un insieme di strumenti di osservabilità per generare, esportare e raccogliere questi dati (opentelemetry.io).

Il fatto architetturale fondamentale è che non si tratta di un pannello di controllo né di un sistema di archiviazione. È il livello di strumentazione indipendente dal fornitore che alimenta la piattaforma di osservabilità scelta — Honeycomb, Datadog, Grafana, SigNoz, New Relic, Google Cloud Observability o Azure Monitor. Strumenti il software una volta e puoi cambiare fornitore senza riscrivere il codice. Google Cloud e Microsoft Azure contribuiscono in modo rilevante all’infrastruttura del progetto: ciò ne conferma la solidità come standard tecnico, ma non rappresenta un’approvazione SEO.

Tracce e span — il modello mentale che conta

L’unico concetto che un SEO senza formazione ingegneristica deve conoscere è il tracciamento. La documentazione di Vercel lo spiega chiaramente: “In observability, tracing is the process of collecting and analyzing how a request or operation flows through your application and through Vercel’s infrastructure. Traces are used to explain how your application works, debug errors, and identify performance bottlenecks” (traduzione) «Nell’osservabilità, il tracciamento consiste nel raccogliere e analizzare il percorso di una richiesta o di un’operazione attraverso l’applicazione e l’infrastruttura di Vercel. Le tracce servono a spiegare come funziona l’applicazione, correggere gli errori e individuare i colli di bottiglia delle prestazioni» (Documentazione Vercel Tracing).

Una traccia è la storia di una singola richiesta dall’inizio alla fine. Ogni passaggio al suo interno è uno span — un’operazione con nome con un’ora di inizio, un’ora di fine e una durata. Renderizzare l’HTML: uno span. Interrogare il database: uno span. Chiamare un’API di terze parti: uno span. Leggi una traccia e vedi esattamente quale span ha consumato il tempo. Questa è la differenza tra “la pagina è lenta” e “la pagina è lenta perché questa singola chiamata al database ha richiesto 2,8 secondi” — che è la differenza tra tirare a indovinare e risolvere.

Metriche, log e i casi limite che mettono in difficoltà

Prima di esaminare il modello basato sui CWV, conviene chiarire alcuni limiti per non attribuire a una traccia — o alla sua assenza — più significato di quanto ne abbia.

Traccia vs. metriche — scegli il segnale giusto. Le tracce preservano la singola richiesta: ogni span, in ordine, per un singolo caricamento di pagina. Le metriche sono misurazioni aggregate nel tempo — tassi, conteggi, distribuzioni — e sono lo strumento migliore per “quanto spesso è lento” piuttosto che “perché questo caricamento di pagina è stato lento.” Evidence for this claim Metrics are aggregated measurements over time (rates, distributions), better suited to trend questions than reconstructing one request; log records can carry the active trace and span IDs for correlation with traces. Scope: OpenTelemetry signal model; not SEO-specific. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Metrics OpenTelemetry: Logs Per il modello di correlazione tra CWV e backend descritto qui sotto serve una traccia, non una metrica: bisogna ricostruire il percorso di una singola richiesta, non una tendenza nel tempo.

I log possono trasportare anche l’ID della traccia. I record di log di OpenTelemetry possono includere gli ID di traccia e span attivi, quindi se il caricamento lento della pagina ha anche generato un errore, una riga di log correlata può riempire i dettagli che gli span di una traccia non catturano — a condizione che la libreria di logging e l’SDK siano configurati per quella correlazione. Evidence for this claim Metrics are aggregated measurements over time (rates, distributions), better suited to trend questions than reconstructing one request; log records can carry the active trace and span IDs for correlation with traces. Scope: OpenTelemetry signal model; not SEO-specific. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Metrics OpenTelemetry: Logs

I nomi degli attributi delle convenzioni semantiche sono versionati. Le convenzioni semantiche di OpenTelemetry (i nomi standard degli attributi di span e metriche) vengono pubblicate in versioni nelle quali ogni attributo può avere un diverso livello di stabilità; in passato alcuni nomi sono stati modificati o stabilizzati. Una query salvata in un pannello di controllo e basata su un vecchio nome può smettere silenziosamente di trovare risultati dopo l’aggiornamento di un SDK o del Collector: non genera errori, ma non restituisce più dati. Evidence for this claim OpenTelemetry semantic conventions are versioned and include different stability levels per attribute; attribute names have been renamed and stabilized across releases. Scope: Current semantic-conventions release verified at version 1.43.0 on fetch date; version number will continue to change. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Semantic conventions

La propagazione deve raggiungere ogni passaggio. La correlazione tra CWV e traccia funziona solo se il contesto viene propagato lungo l’intero percorso: CDN o rete periferica, eventuali proxy e server di origine. Un passaggio che elimina l’intestazione di traccia interrompe silenziosamente il collegamento; vedrai un normale caricamento di pagina senza la traccia associata e potresti concludere erroneamente che non sia accaduto nulla.

Il campionamento significa che una traccia mancante non è prova di nulla. La maggior parte delle tracce in produzione è campionata per controllare costi e volume. Se un caricamento di pagina lento specifico non ha una traccia, può significare che non è stato campionato — non che non sia avvenuta alcuna richiesta o errore. Evidence for this claim Sampling trades completeness for cost and throughput, so the absence of a sampled trace is not proof that no request or failure occurred. Scope: OpenTelemetry sampling concept. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Sampling Non leggere l’assenza di traccia come prova di assenza.

Non mettere URL grezzi o stringhe di query negli attributi delle metriche. Sono accettabili in uno span di traccia, progettato per contenere dettagli della singola richiesta, ma inserirli in un attributo di metrica crea una cardinalità illimitata: può superare i limiti del Collector o del sistema di destinazione e far impennare i costi di archiviazione. Se servono dettagli per URL, occorre usare tracce o log, non etichette di metrica. Evidence for this claim Recording raw URLs, query strings, or other unbounded dimensions as metric attributes can create high cardinality and trigger collector/backend limits or large storage costs. Scope: OpenTelemetry Metrics SDK cardinality limits. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Metrics SDK

Il baggage non è per dati sensibili. Il baggage di OpenTelemetry propaga contesto definito dall’applicazione tra chiamate di servizio, ma non è crittografato end-to-end e non dovrebbe trasportare nulla di sensibile — e, come gli attributi delle metriche, valori di baggage ad alta cardinalità possono aggiungere costi se qualcosa a valle li trasforma in attributi. Evidence for this claim Baggage can propagate application context across services but should not carry sensitive data, and high-cardinality baggage used as attributes can amplify cost. Scope: OpenTelemetry Baggage signal. Confidence: high · Verified: 2026-07-19 OpenTelemetry: Baggage

L’unico caso d’uso reale adiacente alla SEO: correlare i Core Web Vitals con le tracce backend

Questa è la sovrapposizione più concreta e realmente fonteabile, e vale la pena farla bene.

I Core Web Vitals sono un segnale relativo all’esperienza sulla pagina che può incidere sul posizionamento. Gli strumenti basati sui dati sul campo (CrUX) mostrano i valori reali di LCP, INP e CLS; quelli di laboratorio (Lighthouse e PageSpeed Insights) forniscono un punteggio in un ambiente controllato. Come osserva OneUptime, “These metrics alone do not tell you why performance is poor.” (traduzione) «Queste metriche, da sole, non spiegano perché le prestazioni siano scarse.» È proprio questa lacuna che una traccia può colmare.

Il modello documentato dai fornitori di sistemi di osservabilità funziona così: il server inserisce un ID di traccia nella risposta HTML; il browser, usando la libreria open source di Google web-vitals, misura i Core Web Vitals reali per quel caricamento di pagina e li segnala taggati con quello stesso ID di traccia. A quel punto puoi collegare uno specifico valore LCP negativo alla traccia specifica del backend che ha prodotto quella pagina. SigNoz descrive il risultato: “By capturing these metrics with OpenTelemetry and visualizing them in a tool like SigNoz, you get a complete view of frontend performance, tightly correlated with backend traces.” (traduzione) «Catturando queste metriche con OpenTelemetry e visualizzandole in uno strumento come SigNoz, ottieni una visione completa delle prestazioni frontend, strettamente correlate con le tracce backend.»

Una volta che frontend e backend sono collegati, emerge una semplice lettura diagnostica — questa è la mia interpretazione del modello di correlazione, non una citazione letterale della fonte:

• LCP alto + TTFB alto → il ritardo è sul backend. Il server è stato lento a rispondere; esamina gli span (query lenta, API a monte lenta, cache fredda).
• LCP alto + TTFB basso → il server ha risposto velocemente, quindi è un problema frontend: un’immagine principale pesante, CSS o JavaScript che bloccano il rendering oppure risorse caricate in ritardo.
• INP alto → quasi sempre frontend — gestione dell’input con attività onerose sul thread principale, non un problema backend.
• CLS alto → una questione di rendering del frontend (spostamento del layout), non correlata ai tempi backend.

Questa lettura su due assi è il valore reale: invece di indovinare se un problema CWV vive nella tua infrastruttura o nel tuo frontend, sai dove si trova e smetti di sprecare tempo di sviluppo ottimizzando il livello sbagliato. Come lo descrive Embrace, “close the loop between frontend and backend, avoiding endless cycles of trial-and-error fixes” (traduzione) «chiudi il cerchio tra frontend e backend, evitando cicli infiniti di correzioni per tentativi ed errori» — ma si tratta di un messaggio promozionale del fornitore, che va quindi valutato con cautela.

Dove si inserisce nei siti basati soprattutto su JavaScript e nelle architetture headless

Per i siti che usano il rendering lato server o un CMS headless, strumentare il servizio di rendering con OpenTelemetry può mostrare la durata del rendering, i successi e le mancate corrispondenze della cache e dove va il tempo prima che l’HTML raggiunga Googlebot o un utente. Next.js supporta questo direttamente — i suoi documenti dicono “We recommend using OpenTelemetry for instrumenting your apps. It’s a platform-agnostic way to instrument apps that allows you to change your observability provider without changing your code,” (traduzione) «Consigliamo di usare OpenTelemetry per strumentare le applicazioni. È un metodo indipendente dalla piattaforma che permette di cambiare fornitore di osservabilità senza modificare il codice» e che “Next.js supports OpenTelemetry instrumentation out of the box, which means that we already instrumented Next.js itself” (traduzione) «Next.js supporta nativamente la strumentazione OpenTelemetry: ciò significa che Next.js stesso è già stato strumentato» (Guida OpenTelemetry di Next.js).

Inquadra OTel qui come un livello diagnostico sottostante al tuo lavoro di JavaScript-SEO, non un sostituto dello strumento URL Inspection. URL Inspection ti dice cosa ha renderizzato Google; una traccia spiega perché la catena SSR ha impiegato quattro secondi per produrre quell’HTML. Domande diverse, entrambe degne di risposta.

In cosa differisce dall’analisi dei file di log del server

Questa distinzione è il modo più chiaro per inserire OTel in un insieme di strumenti per la SEO tecnica. I file di log del server — la tradizionale fonte primaria della SEO per il comportamento dei crawler — registrano cosa ha richiesto un URL e come il server ha risposto: user-agent, codice di stato, tempo di risposta. Le tracce OpenTelemetry registrano la ripartizione interna di cosa è successo durante quella richiesta attraverso i tuoi servizi.

In parole povere: analisi dei log = visibilità sul comportamento di scansione; tracciamento = visibilità sulla causa principale delle prestazioni. I log ti dicono che Googlebot ha recuperato /product/123 e ha ottenuto un 200 in 1,9 s. Una traccia spiega perché sono serviti 1,9 s: 1,6 s sono stati impiegati da una chiamata al servizio dei prezzi. Sono pratiche complementari, non concorrenti. Se fai già analisi dei file di log, il tracciamento aggiunge naturalmente il livello del “perché” sotto quello del “cosa”.

Chi dovrebbe effettivamente farlo

Per la maggior parte degli SEO, in concreto, è un’iniziativa da proporre o discutere con il team di sviluppo, non un progetto da realizzare in autonomia. I candidati più adatti sono:

• Siti grandi o aziendali con pratiche tecniche di osservabilità già consolidate — che eseguono già Datadog, Honeycomb, Grafana o New Relic sull’applicazione stessa. Per loro, esporre i dati di traccia a un’indagine CWV è una richiesta minima.
• Architetture fortemente basate su JavaScript, SSR o headless nelle quali le prestazioni di rendering rappresentano un problema SEO reale e ricorrente.

Per chi non è: una piccola azienda su Wix, Shopify o Squarespace. Non c’è un server da strumentare e non ne ricaverebbe alcun vantaggio: bastano strumenti CWV più semplici.

Supporto reale e attuale della piattaforma che vale la pena menzionare

Queste sono integrazioni verificabili e attualmente documentate — menziono solo quelle a cui posso fare riferimento:

• Vercel — il pacchetto @vercel/otel, strumentazione automatica dell’infrastruttura, e span automatici del framework per Next.js 13,4+ (Vercel Tracing).
• Next.js — strumentazione OpenTelemetry integrata (Guida Next.js).
• Google Cloud — Cloud Trace tramite OTLP (Google Cloud: Cos’è OpenTelemetry?).
• Microsoft Azure — Application Insights / Azure Monitor.

Non lasciare che nessuno te ne inventi altre — se una “integrazione SEO del fornitore” non è nei documenti del fornitore stesso, trattala come marketing.

Cosa non è

• Non è un fattore di posizionamento. OTel non ha alcuna connessione con i sistemi di posizionamento di Google o Bing. Aiuta a diagnosticare perché i CWV sono scarsi, e i CWV costituiscono un segnale, ma OTel stesso non lo è.
• Non è un sostituto di Search Console / Bing Webmaster Tools. Questi sono i dati di prima parte dei motori su come loro ti indicizzano e ti vedono. OTel è la prestazione interna della tua app — una fonte di dati diversa che risponde a una domanda diversa.
• Non è raccomandato da Google o Bing. Nessun documento di Search Central, post del blog o episodio di Search Off the Record affronta OpenTelemetry in un contesto SEO.
• Non è ancora una pratica diffusa. Nessuna pubblicazione del settore SEO ha trattato questa combinazione e non esistono dati di adozione. Consideralo un argomento che vale la pena conoscere, non qualcosa che tutti stanno già facendo.

Come iniziare, in pratica

Per la maggior parte dei lettori il primo passo è una conversazione, non un file di configurazione: chiedi al team di sviluppo o della piattaforma quali strumenti di osservabilità siano già presenti e se sia possibile usare i dati delle tracce per diagnosticare un problema specifico di CWV o rendering. Se hai competenze tecniche o supporto ingegneristico, il punto di partenza documentato è la correlazione descritta sopra tra Core Web Vitals e tracce del backend; la scheda Script contiene il modello per associare gli ID di traccia ai dati web-vitals da consegnare a uno sviluppatore.

Riepilogo AI

Una sintesi della versione Advanced:

• OpenTelemetry (OTel) è un framework di osservabilità open source e indipendente dal fornitore (un progetto CNCF) che standardizza tracce, metriche e log. È il livello di strumentazione, non un pannello di controllo né un sistema di destinazione.
• Non è uno strumento SEO, non è un fattore di posizionamento e Google/Bing non lo hanno mai raccomandato per la SEO. Non esiste alcuna guida ufficiale né copertura da parte delle principali pubblicazioni SEO: è un ambito emergente e ancora sperimentale.
• Una traccia è la storia di una richiesta; ogni passaggio è uno span con una durata. Leggere le tracce trasforma “la pagina è lenta” in “la pagina è lenta perché questo span.”
• Casi limite da conoscere: le metriche aggregate e le tracce relative alle singole richieste sono strumenti diversi; i log possono includere ID di traccia e span per la correlazione; i nomi degli attributi delle convenzioni semantiche sono versionati e possono smettere silenziosamente di corrispondere dopo un aggiornamento; il campionamento significa che una traccia mancante non prova che non sia accaduto nulla; non inserire URL/query string grezzi sugli attributi delle metriche (cardinalità) o dati sensibili in Baggage.
• L’unico caso d’uso realmente adiacente alla SEO: correlare le Core Web Vitals del frontend con le tracce del backend. Inserisci un ID di traccia nella risposta, registra i CWV tramite la libreria web-vitals, associandoli a quell’ID, e individua dove si trova il problema.
• Diagnostica a due assi (quadro dell’autore): LCP alto + TTFB alto → backend; LCP alto + TTFB basso → frontend; INP alto → gestione input frontend; CLS alto → layout frontend. Ti impedisce di ottimizzare il livello sbagliato.
• Siti basati soprattutto su JavaScript o headless: strumenta SSR e rendering per misurare la durata del rendering e i successi o le mancate corrispondenze della cache. Next.js e Vercel supportano OTel nativamente: è un livello diagnostico sottostante la SEO JavaScript, non un sostituto di URL Inspection.
• Rispetto all’analisi dei file di log: i log mostrano il comportamento di scansione (che cosa è stato recuperato e con quale stato); le tracce mostrano la causa principale delle prestazioni (perché una richiesta era lenta). Sono complementari.
• A chi è destinato: siti grandi o fortemente basati su JavaScript che dispongono già di strumenti tecnici di osservabilità. Non è adatto ai piccoli siti su piattaforme gestite. Per la maggior parte dei SEO è un argomento da discutere con il team di sviluppo.

Documentazione ufficiale

Non esiste alcuna documentazione SEO ufficiale di Google o Bing su OpenTelemetry — questo elenco è la documentazione tecnica del framework e delle piattaforme stesse, che è la fonte primaria corretta per uno strumento ingegneristico.

OpenTelemetry / CNCF

• Cos’è OpenTelemetry? — la definizione del framework: tracce, metriche, log e strumentazione indipendente dal fornitore.
• Segnali — il rapporto tra tracce, metriche e log e i casi in cui usare ciascun segnale.
• Metriche — confronto tra misurazioni aggregate e tracce per singola richiesta.
• Log — il modo in cui i record di log si correlano con tracce e span attivi.
• Convenzioni semantiche — nomi degli attributi versionati e relativi livelli di stabilità (versione corrente verificata: 1.43.0).
• Campionamento — perché l’assenza di una traccia non prova che non sia accaduto nulla.
• Baggage — propagare il contesto senza perdere dati sensibili.
• SDK metriche — limiti di cardinalità — perché URL/query string grezzi non appartengono agli attributi delle metriche.

Supporto nativo delle piattaforme (integrazioni reali e attuali)

• Next.js — Come configurare la strumentazione con OpenTelemetry — strumentazione OTel integrata per Next.js.
• Vercel — Tracciamento — @vercel/otel, strumentazione automatica dell’infrastruttura, span del framework Next.js 13,4+ e una definizione del tracciamento in linguaggio semplice.
• Google Cloud — Cos’è OpenTelemetry? — pagina definitoria generale (non SEO); Cloud Trace tramite OTLP.

Il segnale SEO che aiuta a diagnosticare (fonte da questi, non dalla documentazione OTel)

• web-vitals — la libreria open source di Google Chrome per misurare i Core Web Vitals degli utenti reali; il componente che associa i dati CWV a un ID di traccia.

Citazioni dalla fonte

Poiché non esiste alcuna dichiarazione di Google o Bing su OpenTelemetry per la SEO e nessun giornalista identificabile del settore SEO ne ha parlato, non ci sono citazioni di esperti pertinenti da riportare. Non colmerò il vuoto con una frase solo vagamente collegata ai Core Web Vitals lasciando intendere che riguardi OpenTelemetry. Le citazioni seguenti provengono dalla documentazione del framework e dei fornitori. Ogni collegamento porta direttamente al passaggio citato.

OpenTelemetry — cos’è

• “An observability framework and toolkit designed to facilitate the Generation, Export, Collection of telemetry data such as traces, metrics, and logs.” (traduzione) «Un framework e un insieme di strumenti di osservabilità progettati per facilitare la generazione, l’esportazione e la raccolta di dati di telemetria come tracce, metriche e log». — Documentazione OpenTelemetry. Leggi

Vercel — cosa significa tracing (deep link verificato)

• “In observability, tracing is the process of collecting and analyzing how a request or operation flows through your application and through Vercel’s infrastructure. Traces are used to explain how your application works, debug errors, and identify performance bottlenecks.” (traduzione) «Nell’osservabilità, il tracciamento consiste nel raccogliere e analizzare il percorso di una richiesta o operazione nell’applicazione e nell’infrastruttura di Vercel. Le tracce servono a spiegare il funzionamento dell’applicazione, correggere errori e individuare colli di bottiglia nelle prestazioni». — Documentazione Vercel Tracing. Vai alla citazione

Honeycomb — perché chi si occupa di osservabilità menziona la SEO (deep link verificato)

• “Google uses CWV scores as one of the measures it uses to rank pages, which means they are important for SEO.” (traduzione) «Google usa i punteggi CWV come una delle misure con cui ordina le pagine; ciò significa che sono importanti per la SEO». — Honeycomb, “Osservare i Core Web Vitals con OpenTelemetry,” di Purvi Kanal. Vai alla citazione

OneUptime — il divario che il tracing colma

• “These metrics alone do not tell you why performance is poor.” (traduzione) «Queste metriche, da sole, non spiegano perché le prestazioni siano scarse». — OneUptime, “Correlare i Core Web Vitals con le trace OpenTelemetry del backend,” di Nawaz Dhandala. Leggi

SigNoz — il vantaggio della correlazione frontend-backend

• “By capturing these metrics with OpenTelemetry and visualizing them in a tool like SigNoz, you get a complete view of frontend performance, tightly correlated with backend traces.” (traduzione) «Acquisendo queste metriche con OpenTelemetry e visualizzandole in uno strumento come SigNoz, ottieni una visione completa delle prestazioni del frontend, strettamente correlata alle tracce del backend». — SigNoz, “Tracciare i Web Vitals in Next.js con OpenTelemetry,” di Yuvraj Singh Jadon. Leggi

Embrace — chiudere il ciclo frontend/backend

• “You close the loop between frontend and backend, avoiding endless cycles of trial-and-error fixes.” (traduzione) «Chiudi il ciclo tra frontend e backend, evitando serie interminabili di correzioni per tentativi». — Embrace, “Un approccio incentrato sull’utente ai Core Web Vitals tramite OpenTelemetry,” di Virna Sekuj. Leggi

Next.js — raccomandare OpenTelemetry per l’instrumentazione

• “We recommend using OpenTelemetry for instrumenting your apps. It’s a platform-agnostic way to instrument apps that allows you to change your observability provider without changing your code.” (traduzione) «Consigliamo di usare OpenTelemetry per strumentare le applicazioni. È un metodo indipendente dalla piattaforma che consente di cambiare fornitore di osservabilità senza modificare il codice». — Documentazione Next.js. Leggi

Dovresti prendere in considerazione OpenTelemetry?

Una rapida e onesta panoramica prima che qualcuno strumenti qualsiasi cosa.

Inizio: hai un problema di Core Web Vitals o di rendering che non riesci a spiegare?

• No → Non ne hai bisogno. Risolvi prima ciò che i tuoi normali strumenti CWV evidenziano.
• Sì ↓

Il tuo sito è grande, ricco di JavaScript o renderizzato lato server, con una reale complessità backend?

• No — sito piccolo su una piattaforma ospitata (Wix, Shopify, Squarespace, WordPress di base) → Fermati. Non c’è nulla da strumentare e nessun vantaggio. PageSpeed Insights, CrUX e un buon strumento RUM troveranno il tuo problema.
• Sì ↓

Il tuo team tecnico usa già strumenti di osservabilità (Datadog / Honeycomb / Grafana / New Relic) sull’app?

• Sì → Caso migliore. Non installare nulla da solo — chiedi loro di esporre i dati di traccia per le pagine lente e di correlarli con i CWV. Piccola richiesta, grande vantaggio.
• No, ma abbiamo supporto ingegneristico → È ragionevole proporlo. Inizia con la correlazione CWV-traccia backend (vedi Scripts), limitata al problema specifico — non un’implementazione completa di osservabilità giustificata solo dalla SEO.
• Nessun supporto ingegneristico → Non è un’attività da affrontare in autonomia. Segnala il sintomo (pagine lente che danneggiano l’esperienza di pagina) a chi possiede la piattaforma, non lo strumento.

Una volta che hai una traccia — dove vive il problema CWV?

Se tu (o il tuo sviluppatore) puoi leggere una traccia correlata, questa lettura a due assi ti dice quale livello correggere (mia personale cornice del modello di correlazione):

• LCP alto + TTFB alto → Backend. Il server è stato lento a rispondere — leggi gli span per individuare una query lenta, un’API a monte lenta o una cache fredda.
• LCP alto + TTFB basso → Frontend. Server veloce, visualizzazione lenta — immagine principale pesante, CSS/JS che bloccano il rendering, risorse tardive.
• INP alto → Gestione input frontend — JavaScript pesante sul thread principale. Raramente una correzione backend.
• CLS alto → Layout frontend — riserva spazio per immagini/annunci/embed. Non è una preoccupazione backend.

Lo scopo dell’albero: sapere quale livello prima di spendere uno sprint ottimizzando quello sbagliato.

I modelli mentali

1. Le tracce rispondono al “perché”, i log rispondono al “cosa”. L’analisi dei log del server mostra che cosa ha richiesto un URL e come il server ha risposto (bot, codice di stato, tempo di risposta). Una traccia ti dice perché una richiesta è stata lenta — la suddivisione interna span per span. Livelli complementari: log per il comportamento di scansione, tracce per la causa principale delle prestazioni.

2. Traccia → span → quello lento. Una traccia è l’intera storia di una richiesta; ogni passaggio è uno span con una durata. L’abilità è leggere una traccia per trovare il singolo span che ha consumato il tempo, così “è lento” diventa “è lento a causa di questo.”

3. La lettura CWV a due assi. Incrocia LCP con TTFB per individuare un problema di velocità: alto/alto = backend; alto/basso = frontend; INP alto = input frontend; CLS alto = layout frontend. Questo è il modo più rapido per smettere di ottimizzare il livello sbagliato. (Mia personale cornice, non una citazione di una fonte.)

4. Strumenta una volta, cambia sistema di destinazione. L’intera proposta di valore di OpenTelemetry è la neutralità del fornitore — strumenti la tua app una volta e puoi inviare dati a Honeycomb, Datadog, Grafana, SigNoz o a un fornitore cloud senza riscrivere il codice. Non confondere il framework OTel con il pannello di controllo o con il sistema di destinazione che lo alimenta.

5. Sostieni, non costruire necessariamente. Per la maggior parte degli SEO, la scelta realistica è chiedere a un team di sviluppo che dispone già di strumenti di osservabilità di esporre i dati di traccia per un problema specifico di CWV, non di creare un proprio Collector. Limita l’ambito al problema, non a “adottare l’osservabilità.”

6. Onestà sulla maturità. Presentalo come un approccio emergente e ancora sperimentale. Non esiste un’approvazione ufficiale e nessun dato di adozione. È una tecnica ingegneristica legittima rivolta a un sintomo SEO — utile dove la sovrapposizione è reale, non una nuova disciplina SEO.

Miti ed errori da evitare

Mito: “OpenTelemetry è uno strumento SEO approvato da Google.” Non esiste tale approvazione in nessuna documentazione di Google. Google è un importante contributore a OpenTelemetry a livello di infrastruttura cloud — questo è un fatto ingegneristico, non una raccomandazione di Search. Nessuno in Google ha collegato OTel alla SEO.

Mito: “OpenTelemetry sostituisce Search Console o l’analisi dei log file.” È un segnale completamente diverso: riguarda le prestazioni delle richieste interne dell’applicazione, non il comportamento di scansione del motore di ricerca o i dati sulla visibilità nei risultati. Li integra, non li sostituisce.

Mito: “Hai bisogno di OpenTelemetry per superare i Core Web Vitals.” Non è vero. I CWV possono essere misurati e corretti con gli strumenti di laboratorio e sul campo esistenti (PageSpeed Insights, CrUX, Lighthouse, RUM) senza alcun tracciamento distribuito. Il tracciamento serve a diagnosticare cause profonde difficili da individuare su backend complessi, non come prerequisito per buoni punteggi.

Mito: “Questa è già una pratica comune tra gli SEO.” Non lo è. Nessuna pubblicazione del settore SEO ne parla e non ci sono dati di adozione. Sii trasparente sul fatto che è precoce e rara — “vale la pena conoscerla”, non “la fanno tutti”.

Errore: strumentare un sito minuscolo perché il termine sembra avanzato. Un piccolo sito su una piattaforma gestita non ha nulla da strumentare e non ne ricaverebbe alcun vantaggio. Non spendere tempo di ingegneria qui per inseguire una parola d’ordine — usalo solo dove la complessità del backend è una causa reale e ricorrente di problemi di CWV o di rendering.

Errore: confondere il framework con il pannello di controllo. OpenTelemetry è il livello di strumentazione; i grafici vivono in un backend (Honeycomb, Datadog, Grafana, SigNoz). “Abbiamo OpenTelemetry” non significa che hai un pannello di controllo: serve anche un sistema a cui inviare i dati.

Errore: fidarsi di presunte “integrazioni SEO” dei fornitori. Menziona solo le integrazioni documentate dal fornitore stesso (Vercel, Next.js, Google Cloud, Azure). Se una presunta integrazione OTel-SEO non compare nella sua documentazione, trattala come marketing, non come fatto.

Errore: mettere l’URL su un attributo di metrica invece che su una traccia. Gli URL grezzi e le stringhe di query sono accettabili come attributi di tracce e span: le tracce servono proprio a conservare dettagli per richiesta. Mettili su un attributo di metrica (un’etichetta su un contatore o un istogramma) e crei una cardinalità illimitata, che può superare i limiti del Collector o far impennare i costi di archiviazione. I dettagli per URL appartengono alle tracce o ai log, non alle etichette delle metriche.

Errore: interpretare “nessuna traccia” come “non è successo nulla.” Il tracciamento in produzione è di solito campionato. Un caricamento lento senza una traccia corrispondente può significare semplicemente che non è stata campionata, non che la richiesta non sia mai avvenuta o che nulla fosse lento. Non diagnosticare un valore anomalo dei CWV concludendo “nessuna traccia, nessun problema”.

OpenTelemetry per la SEO — promemoria

Cos’è / cosa non è

Tracce e log a confronto

La lettura a due assi dei CWV (quadro dell’autore, non una citazione dalla fonte)

Supporto reale della piattaforma (verificabile)

• Vercel — @vercel/otel, strumentazione automatica dell’infrastruttura, span Next.js 13,4+
• Next.js — strumentazione OTel integrata
• Google Cloud — Cloud Trace tramite OTLP
• Microsoft Azure — Application Insights / Azure Monitor

Chi dovrebbe preoccuparsene

• ✅ Siti grandi, con molto JavaScript, SSR o architettura headless e strumenti tecnici di osservabilità già presenti
• ❌ Siti piccoli su Wix / Shopify / Squarespace / WordPress di base

Correlare i Core Web Vitals con una traccia backend

Questo è il modello centrale documentato dalle fonti: ottenere un ID di traccia sulla pagina, misurare i Core Web Vitals reali con la libreria web-vitals di Google e segnalarli con tag associati a quell’ID, così un LCP specifico e lento può essere collegato alla traccia backend specifica che lo ha prodotto. Affidalo a uno sviluppatore: è illustrativo, non pronto per l’uso diretto.

Server: esporre l’ID di traccia corrente alla pagina. Su qualsiasi backend strumentato con OpenTelemetry, leggi l’ID di traccia dello span attivo e incorporalo nell’HTML (un tag <meta> è il passaggio più semplice):

// Node/JS server, @opentelemetry/api available on the request
import { trace } from '@opentelemetry/api';

const span = trace.getActiveSpan();
const traceId = span?.spanContext().traceId ?? '';

// inject into the response head:
// <meta name="trace-id" content="<traceId>">

Client: misurare i CWV e segnalarli con tag associati all’ID di traccia. Usa la libreria web-vitals di Google Chrome così i numeri corrispondono a come i CWV vengono misurati realmente:

import { onLCP, onINP, onCLS, onTTFB } from 'web-vitals';

const traceId =
  document.querySelector('meta[name="trace-id"]')?.content ?? '';

function report(metric) {
  navigator.sendBeacon(
    '/rum',
    JSON.stringify({
      traceId,
      name: metric.name,   // LCP, INP, CLS, TTFB
      value: metric.value,
      url: location.pathname,
    })
  );
}

onTTFB(report);
onLCP(report);
onINP(report);
onCLS(report);

L’endpoint /rum inoltra questi dati allo stesso sistema di osservabilità che contiene la traccia, quindi un valore LCP lento si collega direttamente ai relativi span del backend. Applica quindi la lettura a due assi (LCP e TTFB) della scheda Modelli per stabilire se occorre intervenire sul backend o il frontend.

Verifica rapida dell’ID di traccia nella console del browser

Conferma che il server stia effettivamente esponendo un ID di traccia prima di configurare la segnalazione — incolla nella console degli strumenti per sviluppatori:

document.querySelector('meta[name="trace-id"]')?.content || 'no trace-id on page'

Se restituisce no trace-id on page, la strumentazione non sta ancora raggiungendo la risposta HTML — questa è la prima cosa da sistemare.

Estrarre l’ID di traccia da un header di risposta invece

Se la piattaforma restituisce un’intestazione traceparent (W3C Trace Context) invece di un tag meta, recuperala dalla scheda Rete o verificala con curl:

# The W3C traceparent header looks like: 00-<32-hex-trace-id>-<span-id>-01
curl -sI https://example.com/slow-page/ | grep -i traceparent

Il blocco di 32 caratteri esadecimali dopo 00- è l’ID di traccia con cui dovresti correlare. Nessuna risposta? Il servizio edge o la CDN potrebbe rimuoverlo, oppure la rotta potrebbe non essere strumentata: conviene verificarlo con il tuo team di piattaforma.

Strumenti in questo ambito

Il livello di strumentazione

• OpenTelemetry (OTel) — il framework open source: SDK, Collector ed esportatori. È indipendente dal fornitore e alimenta qualsiasi sistema di destinazione compatibile.
• web-vitals — la libreria di Google Chrome per misurare i Core Web Vitals degli utenti reali nel browser; è il componente lato client del modello di correlazione.

Sistemi di osservabilità di destinazione (dove risiedono tracce e pannelli di controllo)

• Honeycomb, Datadog, Grafana (Tempo), SigNoz, New Relic — ricevono dati OTel e forniscono le viste delle tracce e i pannelli di controllo. OTel permette di passare da uno all’altro senza ripetere la strumentazione.
• Google Cloud Observability (Cloud Trace) e Microsoft Azure Monitor / Application Insights — i sistemi nativi delle rispettive piattaforme cloud, entrambi compatibili con OTLP.

Supporto OTel nativo della piattaforma

• Vercel (@vercel/otel) e Next.js (strumentazione integrata) — i punti di ingresso a minor sforzo per siti JS/SSR.

Gli strumenti SEO che questo integra (non sostituisce)

• Google Search Console / Bing Webmaster Tools — la visione di prima parte dei motori; una fonte di dati diversa che risponde a una domanda diversa.
• PageSpeed Insights, CrUX, Lighthouse — misurano i CWV; il tracing OTel spiega il perché di una misurazione negativa.
• Analisi dei file di log del server (Screaming Frog Log File Analyser, o log inviati a BigQuery) — la fonte primaria per il comportamento di scansione; il “cosa” a cui le tracce aggiungono il “perché”.

Risorse che meritano il tuo tempo

I miei scritti correlati

Non ho scritto specificamente su OpenTelemetry — è un argomento emergente di intersezione — ma questo articolo si colloca tra due aree che tratto spesso, e queste sono le letture naturali successive:

• I fondamenti di SEO tecnica in cui questo si inserisce — la mia Guida per principianti alla SEO tecnica inquadra dove performance e rendering si collocano nel quadro più ampio.
• Il lato rendering, che è dove il tracing in stile OTel dà il meglio sui siti pesanti in JavaScript — i miei Problemi e best practice della SEO JavaScript.
• La fonte primaria per capire “che cosa è stato realmente sottoposto a scansione”, che il tracciamento integra — la mia analisi di come il panorama dei crawler sta cambiando in Incontra i nuovi web crawler.

I miei interventi

• Come funziona la ricerca (SlideShare) — la mia spiegazione di scansione, rendering, indicizzazione e posizionamento, utile per comprendere il processo in cui si inserisce la questione delle prestazioni trattata in questo articolo. (La mia dichiarazione di non responsabilità: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.»)

Dal settore

Il miglior materiale esistente su questo argomento è la letteratura di osservabilità lato ingegneria — utile, ma scritta per gli SRE, quindi leggila come “come funziona la tecnica,” non “come la usano gli SEO”:

• Cos’è OpenTelemetry? (OpenTelemetry / CNCF) — la definizione ufficiale del framework.
• Osservare i Core Web Vitals con OpenTelemetry (Honeycomb, Purvi Kanal) — la guida alla strumentazione dei CWV, con l’inquadramento secondo cui i CWV sono rilevanti per la SEO.
• Correlare i Core Web Vitals con le tracce OpenTelemetry del backend (OneUptime, Nawaz Dhandala) — il modello di correlazione tra frontend e backend e il motivo per cui le metriche, da sole, non spiegano le cause.
• Tracciare i Web Vitals in Next.js con OpenTelemetry (SigNoz, Yuvraj Singh Jadon) — un’implementazione concreta in Next.js.
• Un approccio incentrato sull’utente ai Core Web Vitals tramite OpenTelemetry (Embrace, Virna Sekuj) — il quadro “sintomi, non cause” (nota: angolazione di marketing del fornitore).
• Come configurare la strumentazione con OpenTelemetry (documentazione Next.js) — supporto integrato nel framework.
• Tracciamento (documentazione Vercel) — una definizione chiara e semplice del tracciamento e di @vercel/otel.
• web-vitals (Google Chrome) — la libreria che misura i CWV degli utenti reali nel browser.

Mettiti alla prova: OpenTelemetry per la SEO

Cinque domande rapide su cos’è OpenTelemetry e dove si sovrappone alla SEO tecnica. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche