it
EnglishSvenskaDeutschNederlandsFrançaisEspañolItaliano

Lunover Engineering Notes

Checklist SEO per Next.js 16 in produzione

Una checklist pronta per la produzione per la SEO in Next.js 16: metadata, canonical, hreflang, igiene della sitemap, regole robots, schema e release QA automatizzabile.

March 5, 2026By LunoverWork with us

Checklist SEO per Next.js 16 in produzione

La SEO tecnica e soprattutto disciplina operativa. Il modo piu veloce per perdere posizioni e rilasciare una release con canonical incoerenti, metadata duplicati o una sitemap rotta. Questa checklist e scritta per team che costruiscono siti marketing e siti di servizi in Next.js 16 (App Router), soprattutto con piu lingue.

Come si presenta il “fatto”

  • Ogni pagina indicizzabile ha un titolo + descrizione unici che corrispondono all’intento della pagina.
  • Le canonical comprimono i duplicati (host, alias di lingua, trailing slash).
  • Hreflang punta solo a equivalenti reali e include x-default.
  • La sitemap include solo URL canoniche e indicizzabili e un lastmod affidabile.
  • Il JSON-LD corrisponde al contenuto visibile della pagina.
  • Puoi verificare tutto quanto sopra nell’HTML renderizzato.

1. I metadata appartengono alla route

Non affidarti a un unico default globale per le pagine “money”. Per ogni route indicizzabile, verifica di generare:
  • title
  • description
  • URL canonica
  • immagine Open Graph / Twitter
Se stai usando metadataBase di Next.js, preferisci valori relativi nel codice e lascia che Next componga URL assoluti. Pattern esempio: 
export const metadata = {
  metadataBase: new URL("https://www.example.com"),
  alternates: {
    canonical: "/services/web-development/",
    languages: {
      en: "/services/web-development/",
      de: "/de/services/web-development/",
      "x-default": "/services/web-development/",
    },
  },
  robots: {
    index: true,
    follow: true,
  },
};
Riferimento: generateMetadata / Metadata API di Next.js.

2. Le canonical devono essere stabili e “opinionated”

Scegli una policy e applicala:
  • un host (per esempio www)
  • una convenzione per il trailing slash
  • una convenzione per il locale di default
Poi redireziona tutto il resto in modo permanente. Se la tua policy canonical e “www + trailing slash + nessun prefisso /en”, assicurati che questi non si risolvano mai come URL indicizzabili separati:
  • https://lunover.com/...
  • https://www.lunover.com/en/...
  • https://www.lunover.com/... (senza trailing slash)

3. Hreflang deve includere solo equivalenti reali

Hreflang non e “traduci l’URL”. E “dichiara pagine equivalenti”. Regole che mantengono puliti i cluster:
  • includi alternates solo per i locali in cui la pagina esiste
  • ogni variante deve referenziare se stessa e lo stesso set di alternates
  • includi x-default puntando alla versione in lingua di default
Riferimento: versioni localizzate di Google (hreflang).

4. Robots riguarda l’intento, non la tradizione

robots.txt controlla il crawling. noindex a livello pagina controlla l’indicizzazione. Usa noindex a livello pagina per pagine che non devono mai apparire in ricerca:
  • pagine utility di chat
  • pagine di tool interni
  • pagine temporanee che non vuoi indicizzare
Nei metadata di Next.js e un campo di prima classe:

5. La sitemap deve essere noiosa e affidabile

Una sitemap non e marketing. E un contratto macchina. Includi solo:
  • URL canoniche
  • URL indicizzabili
  • lastmod accurato
Google raccomanda esplicitamente che lastmod rifletta l’ultimo aggiornamento significativo (contenuto principale, dati strutturati o link), non bump cosmetici del timestamp. Riferimento: linee guida sitemap di Google.

6. I dati strutturati devono corrispondere a cio che gli utenti vedono

Il JSON-LD dovrebbe derivare dalla stessa fonte di verita della pagina. Schemi di base che di solito hanno senso:
  • Organization (site-wide)
  • WebSite (homepage)
  • Service (pagine servizi)
  • BlogPosting (articoli)
Il failure mode da evitare e: “lo schema dice una cosa, la pagina ne dice un’altra”. Riferimento: linee guida dati strutturati di Google.

7. L’internal linking e parte dell’infrastruttura SEO

Se i post tecnici non linkano mai le pagine servizi, i motori di ricerca fanno fatica ad associare la tua competenza agli intenti commerciali. Una regola semplice che scala:
  • ogni post tecnico linka almeno una pagina servizi rilevante
  • ogni pagina servizi linka almeno un post tecnico rilevante
Parti da:

8. Release QA (automatizzabile)

Prima di deployare, verifica sull’HTML renderizzato:
  • titoli/descrizioni sono unici sulle pagine chiave
  • la canonical e corretta e assoluta
  • il set hreflang e corretto
  • il meta robots e corretto (soprattutto noindex)
  • la sitemap renderizza e contiene le URL attese
  • lo schema renderizza e valida
Trattali come gate di deploy. La SEO e troppo sensibile per affidarsi a spot check manuali.

Related