Qué hace realmente un verificador canónico
Un verificador canónico obtiene una URL, analiza la sección HTML <head> en busca de <link rel="canonical" href="...">, lee los encabezados de respuesta HTTP en busca de un encabezado Link: <...>; rel="canonical" y compara los dos. Si ambos están presentes y difieren, hay un conflicto. Si ninguno está presente, la página no tiene un canónico explícito y corre riesgo de problemas de contenido duplicado.
También genera variantes de URL comunes y prueba cada una. Dada https://www.example.com/page, probamos http://www.example.com/page, https://example.com/page, http://example.com/page, https://www.example.com/page/, y https://www.example.com/page?utm_source=test. Cada variante podría devolver un canónico diferente, una redirección, o el mismo canónico que el original. Nuestro verificador mapea los resultados para que vea la imagen completa en una tabla.
Tres problemas aparecen repetidamente. El primero es canónicos entre dominios—donde la etiqueta apunta a un dominio completamente diferente, generalmente después de una migración o mal funcionamiento de CDN. El segundo es cadenas de redirección—donde una URL se canonicaliza a otra URL que redirige a una tercera. El tercero es canónicos faltantes en páginas paginadas o filtradas, lo que lleva a penalizaciones por contenido duplicado.
Cómo usar este verificador canónico
- Pegue su URL en Primary URL. Use la versión que considera canónica—generalmente https, www si la usa, y sin barra diagonal final a menos que su CMS la requiera.
- Pegue variantes adicionales en Extra variants to check si desea probar URLs específicas. Una por línea. Generamos automáticamente las variantes comunes (protocolo, subdominio, barra diagonal final), por lo que este campo es opcional.
- Haga clic en Check canonicals. Obtiene una tabla con una fila por cada URL probada. Cada fila muestra la URL, el código de estado HTTP, el canónico encontrado en la etiqueta HTML, el canónico encontrado en el encabezado HTTP, y si coinciden.
- Mire la columna Conflicts. Una bandera roja significa que el canónico HTML difiere del canónico HTTP, o la URL se canonicaliza a sí misma cuando no debería, o el canónico apunta a una URL que devuelve 404.
- Haga clic en Download report para exportar la tabla como CSV. Úsela para corregir canónicos en masa en su CMS o pásela a un desarrollador.
Intente verificar https://www.example.com/page en un sitio WordPress. Podría descubrir que la versión www se canonicaliza a https://www.example.com/page (sin www) y que la versión sin www se canonicaliza a sí misma. Si ambas versiones devuelven 200, Google podría tratarlas como duplicadas a menos que una redirija a la otra. El verificador muestra este conflicto en un paso.
Por qué las variantes de URL crean contenido duplicado
Google trata https://example.com/page, https://www.example.com/page, http://example.com/page, y https://example.com/page/ como cuatro URLs separadas. Si las cuatro devuelven 200 y muestran contenido idéntico, Google debe adivinar cuál es el original. Las etiquetas canónicas eliminan la conjetura al declarar una URL como fuente. Las otras tres deberían redirigir al canónico o incluir una etiqueta canónica que apunte a él.
Tres consecuencias prácticas.
Dilución de equidad de vínculos. Si la mitad de sus vínculos de retroceso apuntan a la versión www y la mitad a la versión sin www, Google ve dos páginas dividiendo la autoridad. Un canónico consolida esa equidad en una URL.
Desperdicio de presupuesto de rastreo. Si Google rastrea las cuatro variantes, usa cuatro solicitudes para indexar una página. En sitios grandes, esto se multiplica entre miles de páginas. Las etiquetas canónicas o redirecciones 301 detienen la duplicación.
Confusión del índice. Google podría indexar la variante incorrecta—la versión http en lugar de https, o la versión con barra diagonal cuando prefiere sin barra. Una etiqueta canónica le dice a Google cuál mostrar en los resultados de búsqueda.
Canónico HTML vs canónico del encabezado HTTP
El canónico HTML reside en el <head>: <link rel="canonical" href="https://example.com/page">. El canónico del encabezado HTTP reside en los encabezados de respuesta: Link: <https://example.com/page>; rel="canonical". Ambos sirven el mismo propósito. Si ambos están presentes y están de acuerdo, excelente. Si ambos están presentes y no están de acuerdo, Google elige uno—generalmente el encabezado HTTP porque se envía antes de que se analice el HTML.
Los CDN, proxies y redirecciones del lado del servidor a veces añaden canónicos de encabezado HTTP sin que el propietario del sitio lo sepa. Si su CMS envía un canónico HTML que apunta a la URL A, pero su CDN añade un encabezado HTTP que apunta a la URL B, tiene un conflicto silencioso. Nuestro verificador muestra ambos para que pueda detectar falta de coincidencias.
Algunos CMS y frameworks establecen canónicos incorrectamente de forma predeterminada. Shopify a veces canonicaliza URLs de productos a la primera colección en la que aparecen, incluso si el producto está en cinco colecciones. Las instalaciones multisitio de WordPress pueden canonicalizar al subdominio incorrecto si la configuración de URL del sitio es antigua. Probar variantes revela estos casos extremos.
Canónicos auto-referenciadores y cuándo importan
Un canónico auto-referenciador significa que la etiqueta canónica de la URL apunta a sí misma: <link rel="canonical" href="https://example.com/page"> en https://example.com/page. Esto es correcto para la versión canónica de una página. Le dice a Google "esto es el original, no una copia".
Sin embargo, si una variante es auto-referenciadora—https://example.com/page/ se canonicaliza a sí misma en lugar de la versión sin barra—tiene un problema. Google ve dos URLs auto-referenciadores con contenido idéntico y debe elegir una. La mejor solución es redirigir 301 la versión con barra a la versión sin barra o canonicalizar la versión con barra a la versión sin barra.
Las URLs paginadas—/blog/page/2, /blog/page/3—deberían canonicalizarse a sí mismas, no a /blog, porque cada página tiene contenido único. Las URLs filtradas u ordenadas—/products?sort=price—a menudo deberían canonicalizarse a la versión sin filtrar /products porque el contenido se superpone. Nuestro verificador no aplica estas reglas automáticamente; muestra el canónico que establece e identifica inconsistencias. Usted decide la política.
Errores comunes
- Cada URL canonicalizándose a la página de inicio. Algunos plugins y temas se establecen de forma predeterminada en esto. Le dice a Google que cada página es una copia de la página de inicio. Verifique una página profunda—una publicación de blog o producto—para confirmar que se canonicaliza a sí misma, no a
/. - El canónico apunta a un 404. Después de una migración o cambio de URL, las páginas antiguas aún pueden canonicalizarse a URLs que ya no existen. Nuestro verificador obtiene la URL canónica e informa el código de estado. Si es 404, elimine el canónico o actualícelo.
- El canónico apunta a una redirección. Si el canónico es
https://example.com/oldpero esa URL redirige 301 a/new, Google tiene que seguir la redirección. Es mejor canonicalizar directamente a/new. - Usar URLs relativas en la etiqueta canónica.
<link rel="canonical" href="/page">funciona en la mayoría de navegadores pero es técnicamente inválido. Use URLs absolutas:href="https://example.com/page". - Canonicalizar http a https pero no redirigir. Si la versión http se canonicaliza a https pero aún devuelve 200, los usuarios en la URL http ven advertencias de contenido mixto y se quedan en http. Una redirección 301 es mejor que una etiqueta canónica para cambios de protocolo.
- Probar solo la versión canónica. Necesita probar las variantes para ver qué hacen. Si la versión www no se canonicaliza a la versión sin www, tiene un duplicado.
Consejos avanzados
- Pruebe una URL de cada tipo de página: página de inicio, categoría, producto, publicación de blog, archivo paginado. Los canónicos a menudo difieren por plantilla, y un problema en una plantilla afecta todas las páginas que la usan.
- Verifique los parámetros de consulta.
?utm_source=twittery?ref=emaildeberían canonicalizarse a la URL limpia si el contenido es idéntico. Si no lo hacen, está creando variantes infinitas. - Busque canónicos entre dominios después de una migración. Si se movió de
old-domain.comanew-domain.compero olvidó actualizar canónicos, las páginas en el nuevo dominio aún pueden canonicalizarse al antiguo. Esto le dice a Google que indexe el sitio antiguo. - Si usa etiquetas hreflang para páginas localizadas, confirme que cada variante de idioma se canonicaliza a sí misma. Un error común es tener todas las versiones de idioma canonicalizarse a la URL en inglés.
- Verifique en masa canónicos en su mapa del sitio. Si su mapa del sitio lista 500 URLs, un script puede llamar a este verificador en un bucle y exportar un CSV de cualquiera que no sea auto-referenciador. Detecte problemas antes que Google.
- Recompruebe después de desplegar un nuevo tema, plugin o actualización de CMS. La lógica canónica puede romperse silenciosamente cuando una dependencia cambia.
Si su verificación canónica revela conflictos, corríjalos en su configuración de CMS o código de tema, luego ejecute nuevamente el verificador. Si también necesita confirmar que su mapa del sitio solo incluye URLs canónicas, use el verificador de mapa del sitio para hacer una referencia cruzada. Para ver cómo los metadatos completos de su página—título, meta descripción, etiquetas OG y canónico—se renderizan en Google, Twitter y LinkedIn, el verificador de metadatos del sitio web previsualizaiza todos lado a lado. Si desea confirmar que Googlebot puede alcanzar la URL canónica y no está bloqueado por robots.txt, la lista de verificación SEO ejecuta 20 verificaciones en la página incluyendo validación canónica.