El Problema del Contenido Duplicado en SEO Técnico y Arquitectura Web
El SEO Técnico es la columna vertebral de cualquier estrategia de posicionamiento web duradera. Dentro de este dominio, el manejo del contenido duplicado representa uno de los desafíos más críticos para arquitectos de software y desarrolladores web. Para un motor de búsqueda como Google, las variaciones de una misma dirección web —por ejemplo, http://dominio.com, https://dominio.com, https://www.dominio.com y https://dominio.com/— son interpretadas formalmente como cuatro recursos independientes. Si un servidor web responde con el mismo contenido exacto para cada una de estas combinaciones sin consolidar la autoridad mediante un encabezado o etiqueta canonical, los algoritmos de rastreo distribuyen el PageRank entre múltiples URLs en lugar de concentrarlo en una sola versión maestra. Esta fragmentación de autoridad debilita el rendimiento orgánico global del dominio y consume de forma ineficiente el Crawl Budget asignado por los bots de rastreo.
Para mitigar este problema en aplicaciones web modernas renderizadas en el servidor (SSR) mediante Node.js y el motor de plantillas EJS, es fundamental contar con un mecanismo automatizado, dinámico y resiliente. Un error común en implementaciones novatas es codificar de forma rígida (hardcode) las URLs en las vistas o construir manualmente las etiquetas dentro de cada controlador. Esta práctica no solo genera una deuda técnica considerable, sino que también provoca fallos cuando el código migra entre entornos de desarrollo local, entornos de pruebas (staging) y servidores de producción con soporte SSL/TLS habilitado.
Arquitectura del Problema en Aplicaciones SSR con Express y EJS
Una arquitectura limpia requiere separar estrictamente la lógica de construcción de URLs de la capa de presentación. En aplicaciones basadas en Express.js, el enfoque óptimo consiste en implementar un middleware personalizado que intercepte todas las solicitudes entrantes antes de que alcancen las rutas o controladores finales. Este middleware analiza la solicitud HTTP actual, consulta las variables de entorno para determinar el dominio base configurado y realiza una desinfección rigurosa de la cadena de texto para evitar incoherencias de formato.
Al delegar esta responsabilidad a un middleware, aprovechamos el objeto res.locals de Express. Este objeto permite pasar variables globales a todas las plantillas EJS que se rendericen durante el ciclo de vida de la petición actual, eliminando la necesidad de inyectar manualmente propiedades de canonicalización en cada llamada a res.render().
Sanitización de URLs: Casos Borde y Expresiones Regulares
Durante el proceso de sanitización de la URL canonical, se deben contemplar varios casos borde esenciales:
- Barras diagonales duplicadas (Trailing Slashes): La variable de entorno que define la dirección base (
BASE_URL) puede haber sido configurada por los operadores de infraestructura con o sin una barra diagonal al final. Aplicar expresiones regulares para eliminar cualquier carácter/sobrante garantiza que la concatenación posterior no resulte en URLs malformadas comohttps://ejemplo.com//blog. - Parámetros de Consulta (Query Parameters): Es crucial extraer únicamente la ruta del recurso (pathname) e ignorar los parámetros de consulta de seguimiento, como los parámetros UTM de campañas publicitarias (
?utm_source=facebook) o tokens de ordenamiento. Incluir parámetros dinámicos en la etiqueta canonical destruye el propósito de la consolidación SEO, ya que cada variación de campaña crearía una URL canonical teóricamente única. - Normalización a minúsculas: Las URLs en servidores web suelen ser sensibles a mayúsculas y minúsculas dependiendo de la configuración. Normalizar la ruta a minúsculas ayuda a evitar la duplicación si un usuario accede a
/Productosen lugar de/productos.
Tratamiento de Respuestas de Error y Renderizado Seguro en EJS
Otro aspecto fundamental es el tratamiento de las respuestas de error. Páginas de estado HTTP de error como 404 (Not Found) o 500 (Internal Server Error) jamás deben exponer una etiqueta canonical activa que apunte a sí mismas o a la página principal. Indicar a Googlebot que una página de error 404 es la versión canonical de un recurso puede provocar la desindexación no deseada de secciones enteras del sitio.
Por ello, en el manejo de excepciones de los controladores o middlewares de captura de errores, la variable canonicalUrl debe ser explicitamente anulada (asignada como null) antes de renderizar la plantilla de error. De esta manera, la vista EJS evaluará defensivamente la condición <% if (locals.canonicalUrl) { %> y omitirá la etiqueta por completo.
Proxies Inversos y Encabezados X-Forwarded
En entornos de producción avanzados donde la aplicación Node.js se ejecuta detrás de un proxy inverso como Nginx, HAProxy o un balanceador de carga de AWS (ALB), es imprescindible gestionar correctamente los encabezados HTTP X-Forwarded-Proto y X-Forwarded-Host. Aunque una variable de entorno BASE_URL suele ser suficiente para definir el dominio canónico principal, entender cómo el tráfico seguro HTTPS es descargado (SSL Offloading) en la capa del proxy evita redirecciones infinitas o discrepancias entre el protocolo reportado por Express y la URL final deseada. La combinación de variables de entorno estrictas con un middleware de sanitización centralizado ofrece la solución más robusta y mantenible para el SEO técnico en proyectos Express y EJS.