Rilevamento della lingua basato su Edge usando l’intestazione Accept-Language per coerenza SEO

I siti web che si rivolgono a pubblico multilingue affrontano una tensione costante tra fornire la versione linguistica corretta ai visitatori umani e garantire una struttura prevedibile per i crawler dei motori di ricerca. La tradizionale negoziazione della lingua lato server può introdurre latenza, aggiungere complessità agli strati di caching e talvolta produrre URL incoerenti che confondono i bot di ricerca.

Distribuire il rilevamento della lingua al “edge” — proprio dove la richiesta incontra per la prima volta la rete di distribuzione dei contenuti (CDN) — offre un’alternativa leggera e a bassa latenza. Leggendo l’intestazione Accept‑Language (AL), una funzione edge può decidere quale variante localizzata servire, riscrivere l’URL della richiesta o instradare a una risorsa pre‑generata specifica per lingua. Se eseguita correttamente, questo approccio produce un unico URL canonico per lingua, annotazioni hreflang coerenti e risposte cache‑abili che rispettano le politiche TTL della CDN.

Di seguito analizziamo i componenti essenziali di una pipeline di rilevamento della lingua basata su edge, discutiamo il design della chiave di cache, esploriamo i meccanismi di fallback e descriviamo i passaggi di implementazione ottimizzati per la SEO.

Perché elaborare la lingua al Edge

Elaborare la lingua al edge fornisce tre vantaggi fondamentali per la SEO multilingue:

1. Riduzione del Round‑Trip Time – I nodi edge sono geograficamente più vicini agli utenti finali, riducendo la latenza del passo di negoziazione iniziale.
2. Efficienza del caching – Incorporando la decisione della lingua nella chiave di cache, lo stesso contenuto può essere memorizzato una volta per variante linguistica, evitando che l’intestazione “Vary: Accept‑Language” bypassi la cache della CDN.
3. URL prevedibili – Le riscritture al edge possono mappare una richiesta generica (example.com) a un percorso specifico per lingua (example.com/it/), preservando la struttura di URL statici preferita dai motori di ricerca.

Questi benefici si traducono direttamente in migliori Core Web Vitals, tassi di rimbalzo più bassi e un segnale di scansione più chiaro per i motori di ricerca.

Anatomia di un flusso di richieste Edge

Il diagramma Mermaid seguente illustra un tipico flusso dal browser del client alla funzione edge, passando per il rilevamento della lingua e, infine, al server origin o alla risposta cache‑ata.

  flowchart TD
    A["Client Browser"] --> B["Edge Node (CDN)"]
    B --> C["Read Accept-Language Header"]
    C --> D{"Supported Language?"}
    D -- Yes --> E["Map to Language Path"]
    D -- No --> F["Apply Fallback Logic"]
    E --> G["Construct Cache Key (URL + Lang)"]
    F --> G
    G --> H{"Cache Hit?"}
    H -- Hit --> I["Serve Cached Variant"]
    H -- Miss --> J["Fetch From Origin"]
    J --> K["Store Variant in Cache"]
    K --> I
    I --> L["Response to Client"]

Il diagramma mette in evidenza due punti decisionali: verificare che la lingua richiesta sia supportata e gestire i casi di cache hit versus miss. Ogni ramo conduce a un URL deterministico che i motori di ricerca possono indicizzare.

Progettazione della chiave di cache

Una chiave di cache ben costruita è il perno di una soluzione edge. La chiave dovrebbe contenere:

• Il percorso della richiesta normalizzato (es. /prodotti/123/).
• Il codice lingua risolto (es. it, fr, es).

Un tipico formato di chiave di cache è /<lingua>/<percorso>. Ad esempio, una richiesta per /prodotti/123/ con un’intestazione AL che indica francese (fr) genererebbe la chiave /fr/prodotti/123/.

Evita di utilizzare l’intestazione Vary per la lingua perché molte CDN trattano Vary: Accept-Language come un bypass della cache, disabilitando di fatto il caching al edge. Inserendo la lingua direttamente nella chiave di cache, mantieni la capacità della CDN di servire copie cache per ogni variante linguistica.

Implementazione della funzione Edge

Di seguito è riportato un esempio di pseudocodice per un runtime edge generico (es. Cloudflare Workers, Fastly Compute@Edge o AWS Lambda@Edge). La logica è deliberatamente indipendente dal linguaggio e può essere adattata a qualsiasi runtime compatibile con JavaScript.

export async function handle(event) {
  const request = event.request
  const url = new URL(request.url)

  // 1. Extract Accept-Language header
  const acceptLang = request.headers.get('Accept-Language') || ''
  
  // 2. Parse header into ordered list of language tags
  const languages = parseAcceptLanguage(acceptLang)

  // 3. Determine the first supported language
  const supported = ['en', 'es', 'fr', 'de', 'zh']
  let chosenLang = supported[0] // default fallback
  for (const lang of languages) {
    const base = lang.split('-')[0] // ignore region subtags
    if (supported.includes(base)) {
      chosenLang = base
      break
    }
  }

  // 4. Rewrite URL to include language segment
  if (!url.pathname.startsWith(`/${chosenLang}/`)) {
    url.pathname = `/${chosenLang}${url.pathname}`
  }

  // 5. Create a new request with the rewritten URL
  const newRequest = new Request(url, request)

  // 6. Let the CDN handle caching based on the new URL
  return fetch(newRequest)
}

// Helper: simple Accept-Language