Canonical Next.js sul dominio sbagliato: le cause che abbiamo verificato

Se una pagina Next.js genera un canonical sul vecchio dominio, cambiare metadataBase può non risolvere nulla. Nel nostro caso con URL assoluto, la base corretta ha lasciato intatto il vecchio indirizzo. È stato necessario modificare alternates.canonical nella pagina. Parti dall’URL realmente prodotto e risali alla configurazione che lo definisce.

Che cosa abbiamo verificato

Il 4 ottobre 2026 abbiamo creato un ambiente App Router separato con Next.js 15.5.22, React 19.2.6 e Node.js v25.2.1. Prima delle misure abbiamo definito otto configurazioni: un controllo corretto e sette casi deliberatamente errati. Ogni coppia prima/dopo appartiene alla stessa build di produzione e cambia una sola impostazione dei metadati. Il controllo rimane invariato.

Abbiamo richiesto ogni URL due volte: 32 risposte HTTP per 16 URL. Poi abbiamo esaminato tutti i 16 documenti renderizzati nel browser. Ogni risposta aveva stato 200 e un solo canonical in head. Le due serie HTTP e il DOM coincidevano. Le sette incongruenze introdotte sono scomparse dopo le rispettive correzioni. Non abbiamo misurato la diffusione di questi errori nei siti reali.

I percorsi /cXX/before e /cXX/after separano i casi. I canonical dichiarati usano domini riservati example.com e percorsi dimostrativi, diversi dagli URL locali. L’ambiente è contrassegnato noindex, nofollow.

Otto configurazioni e indirizzi osservati

Lo stato HTTP 200 non distingueva i metadati corretti da quelli errati. Verifica l’intero URL, compresi percorso e lingua. In C04, Next.js ha emesso l’indirizzo della home senza slash finale: restava comunque la destinazione sbagliata per il prodotto previsto.

Individuare l’impostazione responsabile

Dominio errato con canonical relativo — C02, C05 e C08. Controlla metadataBase nel layout principale e in quelli annidati. Rimuovere la sovrascrittura annidata ha corretto C05. In C08 abbiamo sostituito l’origine preview della variabile di build con il dominio pubblico previsto.

Dominio errato con canonical assoluto — C03. La pagina forniva già l’URL completo sul vecchio dominio. La metadataBase corretta non lo ha sostituito. Correggi quel valore o la sua origine e ricontrolla il tag.

Una scheda prodotto punta alla home — C04. La pagina ereditava il canonical dal layout. Definire alternates.canonical nella pagina ha ripristinato il percorso previsto. Verifica anche gli altri modelli interessati.

Dominio corretto, percorso errato — C06 e C07. Il prefisso /catalog è rimasto anche con un canonical che iniziava per /. Eliminare quel percorso indesiderato dalla base ha corretto C06; aggiungere /fr ha corretto C07. Mantieni i prefissi necessari al tuo deployment.

Una configurazione esplicita da adattare

Per un sito alla radice del dominio, imposta l’origine nel layout e il percorso nei metadati della pagina. È lo schema corretto di C02. Sostituisci dominio e percorso; un sito in una sottocartella richiede una regola specifica.

// app/layout.tsx
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
};

// app/products/widget/page.tsx
export const metadata = {
  alternates: { canonical: "/products/widget" },
};

Se la pagina contiene invece il vecchio URL assoluto mostrato sotto, modificare il solo layout non basta. C03 cambia esclusivamente quel canonical.

// C03 — before
alternates: {
  canonical: "https://old.example.com/products/widget"
}

// C03 — after
alternates: {
  canonical: "https://www.example.com/products/widget"
}

Verificare la build e il documento del browser

1. Crea una build di produzione con la configurazione del dominio pubblico previsto. Controlla anche il deployment se hosting, middleware o CDN possono modificare la risposta.
2. Salva la risposta HTTP e controlla i canonical in head: href completo, numero di tag ed eventuale header Link che indichi un’altra destinazione.
3. Esamina il documento renderizzato negli strumenti del browser. L’espressione seguente elenca tag e posizione. Una differenza fra HTML e DOM richiede un’indagine separata.
4. Ripeti dopo la modifica su schede, percorsi annidati e traduzioni. Registra per ogni verifica URL osservato e destinazione prevista.

Array.from(document.querySelectorAll('link[rel="canonical"]'))
  .map(link => ({
    href: link.getAttribute("href"),
    inHead: link.closest("head") !== null
  }));

C08 verifica una variabile, non l’infrastruttura Vercel. Vercel documenta il noindex abituale delle preview e un’eccezione per i domini personalizzati su branch non di produzione. Controlla gli header del deployment effettivo.

• Vercel: indicizzazione delle preview

Che cosa non dimostra l’esperimento

I risultati coprono una versione, export statici dei metadati e un server locale di produzione. Non abbiamo verificato streaming metadata, Pages Router o tutte le piattaforme. Un canonical conforme non prova che Google lo sceglierà, indicizzerà la pagina o ne migliorerà la posizione. La canonicalizzazione combina più segnali; verifica separatamente la scelta di Google in Search Console, se hai accesso.

• Documentazione Next.js 15
• Google: URL canonici

Dati e riproduzione

Ripetizione aggiuntiva del 13 ottobre 2026: abbiamo fissato le stesse sorgenti archiviate in un commit Git prima della nuova build. Tutte le 32 osservazioni HTTP del canonical e le 16 verifiche DOM coincidono con i risultati originali. L’archivio include le prove con data distinta; lo studio del 4 ottobre resta invariato.

Il pacchetto include protocollo, hash, risultati e ambiente eseguibile. Lo script raccoglie risposte HTTP; l’ispezione del browser è descritta separatamente. Le dipendenze dirette sono fissate, ma il pacchetto autonomo non blocca tutte quelle transitive.

• Risultati osservati · JSON
• Metodo e riproduzione · TXT
• Ambiente, raccolta e prove originali · ZIP

Quando il problema coinvolge più modelli

Prepara una consegna concreta: URL interessato, canonical emesso, destinazione voluta, impostazione responsabile e verifica ripetuta. Se sono coinvolti layout, lingue e ambienti, il nostro audit SEO Next.js può mappare le dipendenze e definire le priorità di implementazione.

• Audit SEO Next.js: ambito e risultati
• Controlli di indicizzazione Next.js

Se i metadati compaiono nel body, il nostro esperimento Next.js su nove condizioni distingue HTML ricevuto e DOM, verificando la posizione di canonical rispetto alle indicazioni di Google.

• Metadati Next.js nel body: nove condizioni verificate

• Indicizzazione Google: individuare il passo successivo