Detección de Idioma basada en Edge usando la Cabecera Accept-Language para la Consistencia SEO

Los sitios web que se dirigen a audiencias en varios idiomas enfrentan una tensión constante entre ofrecer la versión de idioma correcta a los visitantes humanos y proporcionar una estructura predecible para los rastreadores de motores de búsqueda. La negociación de idioma tradicional del lado del servidor puede introducir latencia, añadir complejidad a las capas de caché y, a veces, resultar en URL inconsistentes que confunden a los bots de búsqueda.

Desplegar la detección de idioma en el edge —justo donde la solicitud encuentra por primera vez la red de entrega de contenido (CDN)— ofrece una alternativa ligera y de baja latencia. Al leer la cabecera Accept‑Language (AL), una función de edge puede decidir qué variante localizada servir, reescribir la URL de la solicitud o enrutar a un recurso pre‑generado específico por idioma. Cuando se hace correctamente, este enfoque produce una única URL canónica por idioma, anotaciones hreflang consistentes y respuestas cacheables que respetan las políticas TTL de la CDN.

A continuación describimos los componentes esenciales de una canalización de detección de idioma basada en edge, analizamos el diseño de la clave de caché, exploramos los mecanismos de reserva y detallamos los pasos de implementación orientados al SEO.

Por qué procesar el idioma en el edge

Procesar el idioma en el edge aporta tres ventajas clave para el SEO multilingüe:

1. Reducción del tiempo de ida y vuelta – Las ubicaciones edge están geográficamente más cerca de los usuarios finales, lo que acorta la latencia del paso inicial de negociación.
2. Eficiencia de la caché – Al incorporar la decisión de idioma en la clave de caché, el mismo contenido puede almacenarse una vez por variante de idioma, evitando que el encabezado “Vary: Accept‑Language” haga que la CDN omita la caché.
3. URL predecibles – Las reescrituras en el edge pueden mapear una solicitud genérica (example.com) a una ruta específica por idioma (example.com/es/), manteniendo la estructura estática de URL que favorecen los motores de búsqueda.

Estos beneficios se traducen directamente en mejores Core Web Vitals, menores tasas de rebote y una señal de rastreo más clara para los motores de búsqueda.

Anatomía de un flujo de solicitud en el edge

El siguiente diagrama Mermaid ilustra un flujo típico desde el navegador del cliente hasta la función de edge, pasando por la detección de idioma y, finalmente, al servidor de origen o la respuesta cacheada.

  flowchart TD
    A["Navegador del Cliente"] --> B["Nodo Edge (CDN)"]
    B --> C["Leer Cabecera Accept-Language"]
    C --> D{"¿Idioma compatible?"}
    D -- Sí --> E["Mapear a la Ruta de Idioma"]
    D -- No --> F["Aplicar Lógica de Reserva"]
    E --> G["Construir Clave de Caché (URL + Idioma)"]
    F --> G
    G --> H{"¿Caché encontrada?"}
    H -- Sí --> I["Servir Variante Cacheada"]
    H -- No --> J["Obtener del Origen"]
    J --> K["Almacenar Variante en Caché"]
    K --> I
    I --> L["Respuesta al Cliente"]

El diagrama enfatiza dos puntos de decisión: verificar que el idioma solicitado esté soportado y manejar aciertos o fallos de caché. Cada rama conduce a una URL determinista que los motores de búsqueda pueden indexar.

Diseño de la clave de caché

Una clave de caché bien diseñada es el punto de apoyo de la solución basada en edge. La clave debe contener:

• La ruta de solicitud normalizada (por ejemplo, /productos/123/).
• El código de idioma resuelto (por ejemplo, en, fr, es).

Un formato típico de clave de caché es /<idioma>/<ruta>. Por ejemplo, una solicitud a /productos/123/ con una cabecera AL que indique francés (fr) generaría la clave /fr/productos/123/.

Evita usar el encabezado Vary para el idioma porque muchas CDNs tratan Vary: Accept-Language como una bypass de caché, desactivando efectivamente el caching en el edge. Al incrustar el idioma directamente en la clave de caché, conservas la capacidad de la CDN para servir copias cacheadas para cada variante de idioma.

Implementación de la función de edge

A continuación, un ejemplo de pseudocódigo para un runtime genérico de edge (p. ej., Cloudflare Workers, Fastly Compute@Edge o AWS Lambda@Edge). La lógica es deliberadamente agnóstica respecto al lenguaje y puede adaptarse a cualquier entorno compatible con JavaScript.

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

  // 1. Extraer la cabecera Accept-Language
  const acceptLang = request.headers.get('Accept-Language') || ''
  
  // 2. Parsear la cabecera a una lista ordenada de etiquetas de idioma
  const languages = parseAcceptLanguage(acceptLang)

  // 3. Determinar el primer idioma soportado
  const supported = ['en', 'es', 'fr', 'de', 'zh']
  let chosenLang = supported[0] // fallback por defecto
  for (const lang of languages) {
    const base = lang.split('-')[0] // ignorar subtags de región
    if (supported.includes(base)) {
      chosenLang = base
      break
    }
  }

  // 4. Reescribir la URL para incluir el segmento de idioma
  if (!url.pathname.startsWith(`/${chosenLang}/`)) {
    url.pathname = `/${chosenLang}${url.pathname}`
  }

  // 5. Crear una nueva solicitud con la URL reescrita
  const newRequest = new Request(url, request)

  // 6. Dejar que la CDN gestione la caché basada en la nueva URL
  return fetch(newRequest)
}

// Helper: parser simple de Accept-Language
function parseAcceptLanguage(header) {
  return header
    .split(',')
    .map(part => part.split(';')[0].trim())
    .filter(Boolean)
}

Puntos clave del código

• Extracción y análisis de la cabecera Accept-Language para obtener una lista de preferencias del usuario.
• Selección del idioma que se encuentre entre los soportados, con un fallback predefinido.
• Reescritura de la URL añadiendo el segmento de idioma, lo que genera automáticamente una