Correggere un canonical URL che punta allo staging

2026-09-07 Aggiornato: 2026-09-14

Un canonical che punta allo staging è quasi sempre un valore di configurazione dell'URL base viaggiato insieme a una release o a una copia del database; correggi il valore per l'ambiente di produzione, oppure costruisci il canonical a partire dall'host della richiesta invece che da una costante memorizzata. Le pagine live continuano a restituire 200 per tutto il tempo, motivo per cui questo problema si scopre di solito in un grafico del traffico piuttosto che in un avviso.

Come si presenta il sintomo

Ogni pagina sul sito live serve un canonical che nomina un host diverso:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
<link rel="canonical" href="https://staging.example.com/pricing">

Search Console lo mostra come "Duplicata, Google ha scelto un canonical diverso da quello dell'utente", oppure come pagine che escono dall'indice con un canonical dichiarato dall'utente su un host che non hai mai verificato. Poiché l'host di staging è normalmente irraggiungibile, protetto da password o noindexato, non c'è alcuna destinazione su cui far atterrare il consolidamento, quindi le pagine live smettono semplicemente di posizionarsi una recrawl alla volta. Niente restituisce 500 e nessun controllo di uptime se ne accorge, ed è questo che lo rende costoso.

Da dove viene l'URL base sbagliato

Un database ripristinato dallo staging. In WordPress le righe delle opzioni siteurl e home portano l'hostname di staging in produzione, e ogni URL generato le segue.
Una variabile d'ambiente nella build distribuita. Un URL del sito incorporato al momento della build, così l'output compilato porta con sé il valore di staging indipendentemente da cosa dice l'ambiente di runtime.
Un host predefinito del framework configurato per ambiente, dove la configurazione di produzione non è mai stata aggiornata dopo quella di staging.
Un URL assoluto hardcodato in un layout condiviso o in un'impostazione di un plugin SEO, scritto durante una migrazione e mai più rivisto.
Una pagina in cache costruita sull'host sbagliato. Una CDN o una cache a pagina intera popolata da una build di staging serve HTML obsoleto con il canonical di staging molto tempo dopo che la configurazione è stata corretta.

Correggi il valore, poi elimina la classe del bug

Correggi l'URL base memorizzato per la produzione, in qualunque dei punti sopra si applichi. In WordPress sono le due righe di opzione più qualsiasi URL assoluto scritto nel contenuto dei post dalla copia di staging.
Ricompila e ridistribuisci se il valore è compilato al suo interno. Cambiare una variabile d'ambiente senza una ricompilazione lascia il vecchio valore nel bundle distribuito.
Svuota ogni cache nel percorso, applicazione, CDN ed edge allo stesso modo. Un'origine corretta dietro una cache piena di HTML di staging sembra ancora non risolta finché la cache resta in vita.
Preferisci derivare il canonical dall'host della richiesta piuttosto che leggere una costante memorizzata. Un canonical costruito a partire dall'host che ha servito la richiesta non può essere sbagliato nell'ambiente da cui è stato servito, il che elimina l'intera classe di fallimento invece di questa singola istanza.
Tieni lo staging fuori dall'indice con altri mezzi. L'autenticazione HTTP o una allowlist di IP sull'host di staging è ciò che dovrebbe proteggerlo, non un canonical, e non un noindex che può viaggiare insieme a un file di configurazione.

Verifica la correzione in produzione

Leggi la risposta, non il template, perché plugin, edge worker e cache iniettano tutti canonical che non compaiono nel tuo repository:

curl -s https://example.com/pricing | grep -i 'rel="canonical"'
curl -sI https://example.com/pricing | grep -i '^link:'

Poi controlla più di una pagina. Il canonical è generato da un template, quindi avere la homepage corretta non prova nulla sulle pagine prodotto, sugli elenchi paginati o su qualsiasi cosa renderizzata da un layout diverso. In Search Console, URL Inspection mostra il canonical dichiarato dall'utente accanto a quello selezionato da Google, e i due che coincidono dopo una recrawl è la conferma che conta. Quella recrawl richiede giorni, quindi un canonical corretto non ripristina il traffico lo stesso pomeriggio.

Evita che si ripresenti

Due protezioni costano quasi nulla. La prima è un'asserzione al momento del deploy: dopo una release, recupera una manciata di URL di produzione e fai fallire il deploy se un qualsiasi canonical nomina un host diverso da quello di produzione. La seconda è continuare a sorvegliare in seguito, perché il fallimento ha la stessa probabilità di arrivare con un ripristino del database o un'impostazione di un plugin quanto con un deploy di codice. I controlli HTTP di HostTracker possono asserire sul corpo e sugli header della risposta, quindi un controllo pianificato può essere costruito per fallire quando il tag canonical su una pagina non è quello atteso, e quel fallimento avvisa come qualsiasi altro.

Controlla ogni template, non una pagina

Inizia con un URL interessato nel controllo canonical gratuito: risolve il canonical e segnala quello che punta a un altro host, che è esattamente l'aspetto di un canonical di staging. Poi verifica se il problema riguarda una pagina o un intero layout guardandole tutte insieme. Lo strumento gratuito di crawl del sito percorre il sito e riporta uno stato del canonical per URL, insieme ai flag noindex e ai corpi duplicati che di solito accompagnano un deploy difettoso. Per intercettare il prossimo il giorno stesso in cui viene pubblicato, attiva l'opzione Indexability su un monitor HTTP per le tue pagine chiave: legge il canonical a ogni controllo e invia un avviso quando cambia. Il monitoraggio SEO descrive come funziona.