Decida si las URLs son realmente duplicadas
Una URL canonical es la dirección representativa para páginas duplicadas o casi duplicadas. La relación de enlace canonical es adecuada cuando el objetivo contiene contenido duplicado o un superset del contenido de la página que referencia. No es una forma de ocultar productos distintos, filtros útiles, artículos o locales.
Pregúntese si un visitante perdería contenido importante, opciones o la capacidad de completar una tarea si esta URL fuese representada por la URL candidata. Si la respuesta es sí, manténgala como distinta y mejore su contenido o localización. Si no, elija una URL estable y documente sus reglas de protocolo, host, ruta, barra final y parámetros.
Añada un canonical autorreferente a cada página HTML indexable preferida, incluso cuando hoy no haya duplicados evidentes.
Apunte una copia necesaria, como una ruta con parámetros de analítica, a la URL preferida solo si ambas páginas devuelven el mismo contenido principal.
Use una redirección cuando la URL antigua deba desaparecer
Use una redirección permanente del lado del servidor cuando una ruta antigua, un host retirado o la versión HTTP ya no deba ser destino para visitantes o crawlers. Google trata las redirecciones como una señal fuerte de canonicalización y las recomienda al desaprobar un duplicado.
Use rel=canonical cuando ambas URLs deban responder con contenido pero una deba representar el clúster en búsqueda. La etiqueta no cambia la dirección del visitante ni elimina la otra ruta. El objetivo debe responder con éxito y no debe redirigir ni canonicalizar a otro lado.
Envíe una URL HTTP heredada directamente a la URL final HTTPS y use esa URL HTTPS en todas partes.
Robots.txt, eliminaciones de URL y noindex no expresan un duplicado preferido. Noindex bloquea una página de la búsqueda.
Publique una anotación clara
Para HTML, coloque una anotación rel=canonical absoluta en el head. Revise el código entregado, no solo la configuración del CMS: un tema, plugin, regla de edge o JavaScript puede reemplazar el valor. Google aconseja proporcionarlo en el código HTML y asegurarse de que JavaScript no lo cambie.
Para un documento no HTML como un PDF, use un encabezado de respuesta Link con canonical HTTP cuando corresponda. Evite valores conflictivos en HTML y cabeceras. El objetivo debe ser accesible, no debe devolver un 4xx y no debe ser una URL que redirija o que encadene redirecciones.
Publique un único target canonical por recurso; múltiples objetivos hacen la preferencia poco clara.
Haga fetch de páginas de muestra y cabeceras después de cambios en plantillas, CDN, CMS o enrutamiento y confirme el objetivo final.
Haga que las señales de soporte estén de acuerdo
Enlace internamente a la URL preferida en la navegación, migas, enlaces en el cuerpo y feeds generados. Ponga en el sitemap solo las URLs que desea que aparezcan en búsqueda. La inclusión en el sitemap es una señal más débil, pero refuerza la elección cuando concuerda con redirecciones y anotaciones.
Genere URLs de sitemap completamente calificadas con el mismo host, protocolo y estilo de barra final que el canonical. Elimine duplicados que redirigen y versiones con parámetros. Pruebe sitemaps generados automáticamente tras cambios en permalinks, dominio, idioma o e-commerce.
Reemplace enlaces a URLs con tracking, heredadas o de host alterno por la canonical seleccionada.
Mantenga consistentes las redirecciones HTTPS, los objetivos canonical, sitemaps y enlaces; fallos de certificado o de HTTPS a HTTP envían señales contradictorias.
Trate parámetros, paginación e idiomas según su propósito
Los parámetros no son duplicados automáticamente. Los parámetros de analítica pueden no cambiar el contenido, mientras que filtros y ordenaciones pueden alterar el conjunto de resultados. Pruebe combinaciones representativas. Preserve cualquier parámetro necesario para carrito, inicio de sesión, consentimiento o configuración; un canonical no debe romper un flujo de usuario.
No canonicalice toda una serie paginada a la página uno: las páginas posteriores suelen contener contenido que la página uno no tiene. Para URLs de idioma o país, nombre como canonical la página en el mismo idioma cuando exista y use hreflang para alternas. La canonicalización no sustituye al diseño de localización.
Documente qué filtros son páginas de destino distintas y cuáles son reordenamientos duplicados para que cambios de producto e ingeniería se mantengan alineados.
Use una sola solo cuando sea un superset de contenido usable; pruebe su rendimiento y navegación antes de seleccionarla.
Depure conflictos con evidencia indexada y en vivo
En Search Console, inspeccione la URL afectada y compare el canonical seleccionado por Google con el valor declarado por el usuario. Inspeccione también el objetivo candidato. El informe indexado refleja lo que Google procesó por última vez; una prueba en vivo es útil para el fetch actual, la página renderizada, cabeceras y recursos, pero no puede predecir la selección canonical final.
Si los valores difieren, considere si Google seleccionó el representante mejor. De lo contrario, rastree redirecciones, anotaciones en HTML y encabezados HTTP, salida renderizada, enlaces, entradas de sitemap, hreflang y similitud de contenido. Corrija la discrepancia, registre el cambio y espere la re-evaluación.
Revise plantillas, cabeceras, enrutamiento de host y cambios de seguridad. Un canonical o redirección cross-domain inexplicada requiere investigación de seguridad.
Compare el código entregado y las cabeceras con la configuración del CMS; un plugin o regla de plataforma puede emitir un valor distinto.
Añada comprobaciones de canonical al endurecimiento de lanzamientos SIU
Antes de lanzamientos de dominio, HTTPS, CDN, CMS, plantilla o catálogo, muestree la página de inicio, páginas de contenido y producto, una ruta con parámetros, un locale, una URL heredada y documentos publicados. Registre estado, URL final, objetivo canonical, inclusión en sitemap y un ejemplo de enlace interno.
Mantenga las correcciones reversibles: capture el mapeo actual, cambie un conjunto de reglas, verifique las rutas afectadas y conserve un plan de rollback. Esto apoya la optimización proactiva de la disponibilidad al proteger rutas públicas estables durante un cambio; no proporciona detección de interrupciones ni garantiza indexación.
Asigne reglas canonical entre marketing e ingeniería y registre la plantilla, redirección, sitemap o cambio de plataforma detrás de cada actualización.
Adjunte una pequeña muestra de URL y cabecera antes y después al ticket de lanzamiento para una remediación más rápida.