Correcciones SEO con resultados: URL canónicas, mapas del sitio y barras finales

La mayoría de los consejos de SEO son demasiado genéricos para aplicarlos o demasiado específicos de una plataforma para generalizarlos. Entre las máximas de «escribir buen contenido» y los tutoriales sobre «añadir marcado de esquema a las rutas de navegación», hay una capa intermedia: las buenas prácticas de SEO en la infraestructura que permiten a los buscadores indexar y comprender un sitio de forma fiable. Recibe menos atención de la que merece, aunque suele tener un efecto más constante que las tácticas de contenido.

Tras realizar una auditoría estructurada de SEO y aplicar correcciones en este sitio y en varios sitios de clientes, las mejoras medibles en cobertura de indexación y posiciones fueron sistemáticamente técnicas, no de contenido. No es una conclusión universal: las carencias de contenido suelen ser el factor limitante en sitios con un SEO técnico sólido. Pero en sitios con años de cambios de URL, redirecciones y migraciones de frameworks, la deuda técnica limitaba lo que podía lograr cualquier inversión en contenido.

Inconsistencias en las URL canónicas

Las etiquetas canónicas deberían ser sencillas: la URL canónica es la que se quiere indexar y todas las páginas con el mismo contenido apuntan a ella. En la práctica, las configuraciones cambian con el tiempo y generan ambigüedad en lugar de resolverla.

El patrón más habitual en las auditorías son etiquetas canónicas autorreferenciales cuyo formato de URL difiere del de la página real. Una página servida en https://example.com/products/widget/ cuya etiqueta canónica apunta a https://example.com/products/widget (sin barra final) indica que su versión indexable es una URL que, al solicitarla, redirige a la versión con barra. Los buscadores suelen tolerar esta inconsistencia, pero «suelen tolerar» significa que a veces consolidan correctamente las señales y otras veces reparten el presupuesto de rastreo entre dos señales.

La inconsistencia de mayor impacto se da entre las URL canónicas y las URL hreflang en sitios multilingües. Una página con una etiqueta canónica que apunta a su versión inglesa y etiquetas hreflang que apuntan a sus versiones localizadas obliga al buscador a conciliar dos directrices que dicen cosas distintas sobre la identidad de la página. La documentación de Google deja claro que las etiquetas canónicas y hreflang deben ser coherentes; en la práctica, las configuraciones inconsistentes generan un comportamiento de indexación imprevisible y difícil de diagnosticar sin una auditoría sistemática.

La solución no es complicada: hay que auditar la etiqueta canónica autorreferencial de cada página y comprobar que coincide con la URL servida en todos sus aspectos: protocolo, uso o ausencia de www, barra final y codificación de la URL. La complejidad está en el alcance: en un sitio con cientos de páginas y varios idiomas, hace falta una auditoría programática en lugar de una inspección manual.

Filtrado de mapas del sitio

Un mapa del sitio XML sirve para indicar a los buscadores qué páginas se consideran indexables e importantes. Un mapa que incluye todas las URL —páginas que requieren autenticación, variantes de paginación, páginas de agradecimiento y páginas marcadas con noindex— no cumple ese propósito. Dirige a los rastreadores hacia páginas que no pueden indexarse y diluye la señal sobre cuáles merecen realmente atención.

La mejora de mayor impacto en los mapas del sitio durante las auditorías ha sido eliminar las páginas noindex. Las instrucciones se contradicen cuando una página aparece en el mapa (enviarla para indexación) y también lleva una directiva noindex (no indexarla). Google acabará respetando noindex, pero seguirá rastreando una página que no aporta nada, algo que importa sobre todo en sitios grandes donde el presupuesto de rastreo es una limitación real. Esto también hace que el mapa del sitio sea una guía menos fiable de las páginas que realmente se quieren indexar.

El contenido que requiere autenticación merece especial atención. Las páginas tras un inicio de sesión —paneles de cuenta, historial de pedidos y proceso de pago— no deberían aparecer en mapas del sitio, tengan o no etiquetas noindex explícitas. Si los mapas enviados a Google Search Console incluyen estas URL, generan informes «Page with redirect» o «Crawled — currently not indexed» que añaden ruido a la auditoría y ocultan el estado de las páginas que sí deben indexarse.

Los mapas filtrados —archivos separados por tipo de contenido, como productos, artículos y páginas de destino— ofrecen otra ventaja: permiten analizar con mayor detalle en Google Search Console qué tipos de contenido se indexan de forma eficiente. Un mapa de productos con 200 URL y otro de artículos con 80 permiten monitorear las tasas de indexación por separado e identificar patrones que quedarían ocultos en un único mapa combinado.

Normalización de las barras finales

La cuestión de la barra final es anterior a la carrera profesional de la mayoría de los desarrolladores web actuales y no se ha simplificado. La mayoría de los servidores y frameworks sirven tanto /page como /page/ y redirigen una forma a la otra. Pero la dirección y el código de estado de esa redirección suelen variar en un sitio que ha pasado por varias migraciones de CMS o cambios de framework.

El problema no es que las barras finales inconsistentes confundan a los usuarios: ni siquiera las notan. Es que generan señales de URL duplicadas que reparten el PageRank entre dos direcciones del mismo contenido. Una página con enlaces entrantes a /page y /page/ tiene, en la práctica, el valor de sus enlaces repartido entre las dos versiones, salvo que una etiqueta canónica o una redirección las consolide. Para páginas con un perfil importante de enlaces entrantes, esto supone un costo real en posicionamiento.

La normalización exige coherencia en tres capas: redirecciones de servidor (301) desde la forma no canónica a la canónica, etiquetas canónicas autorreferenciales que utilicen siempre esa forma y enlaces internos que también la utilicen. Muchos sitios implementan una o dos capas sin la tercera, lo que reduce la señal de duplicación, pero no la elimina.

Elegir la forma canónica —con o sin barra final— importa menos que mantener la coherencia. Ambas son válidas. La convención que mejor encaja con la generación de sitios estáticos, donde /page/index.html es la estructura natural de salida, es la forma con barra final; esa es la forma que produce el formato de salida predeterminado de Astro, build.format: 'directory'; Next.js, en cambio, redirige por defecto a la forma sin barra final. La convención que encaja con estructuras de directorios sin barra utiliza la forma sin barra. Cualquiera sirve; el problema es la inconsistencia.

Diagnóstico de indexación en Google Search Console

El informe de cobertura de Google Search Console, ahora llamado indexación de páginas, es el mecanismo más directo para diagnosticar el SEO de un sitio. Sus categorías —«Crawled — currently not indexed», «Discovered — currently not indexed», «Duplicate without user-selected canonical» y «Alternate page with proper canonical tag»— corresponden a situaciones técnicas distintas que requieren soluciones diferentes.

«Crawled — currently not indexed», cuando afecta a un volumen considerable de páginas, suele indicar una de tres situaciones: problemas de calidad en determinados tipos de contenido; señales estructurales de poco valor, como páginas con contenido escaso, muy basado en plantillas o apenas distinto semánticamente de otras; o restricciones del presupuesto de rastreo que llevan a Google a retrasar la indexación incluso de páginas que ya ha obtenido. La solución depende mucho de cuál sea la causa.

«Duplicate without user-selected canonical» casi siempre indica carencias en la normalización de barras finales o en la configuración canónica. Cuando Google encuentra el mismo contenido en dos URL y ninguna tiene una etiqueta canónica que apunte a la otra, selecciona una por su cuenta basándose en sus propias señales; puede que no sea la forma que se quiere indexar. Esta categoría es un indicador fiable de las inconsistencias descritas.

El uso más práctico de Search Console para el monitoreo continuo del SEO no son los informes de posiciones: contienen demasiado ruido por personalización, ubicación y contexto de consulta para resultar útiles operativamente por URL. Los informes de indexación, cruzados con los datos de envío de mapas del sitio, indican directamente si la infraestructura técnica facilita o limita la visibilidad del sitio.

Qué correcciones produjeron resultados

Los datos anteriores y posteriores a estas intervenciones, medidos en un plazo de 60-90 días que, según nuestra experiencia, es lo que Google tarda en procesar y reflejar cambios estructurales, mostraron patrones consistentes. La normalización canónica y la coherencia de las barras finales produjeron las mejoras más claras en las advertencias de GSC sobre duplicados, junto con mejoras de eficiencia del rastreo. El filtrado de mapas del sitio se correlacionó con una mayor cobertura de indexación de páginas prioritarias, posiblemente porque la atención del rastreo pasó de páginas irrelevantes a páginas importantes.

Hay que reconocer que aislar la contribución de cada corrección es difícil. Las intervenciones de SEO se realizan en un sitio que, a la vez, envejece, acumula contenido y se rastrea según el calendario de Google, no el nuestro. La correlación entre una corrección técnica y una mejora de posiciones siempre está condicionada en parte por estos factores simultáneos.

Los datos sí muestran claramente que los sitios con deuda técnica de SEO sin resolver —señales persistentes de duplicación, mapas sobredimensionados e inconsistencias canónicas— rinden por debajo de su potencial, independientemente de la calidad del contenido. Corregir los cimientos no garantiza una mejora de posiciones, pero elimina el límite que impide que otras inversiones alcancen todo su efecto.