Indexación de fragmentos de URL

La indexación de fragmentos de URL es, en su mayor parte, un problema heredado, pero sigue apareciendo en auditorías de SPA cada mes. Si el contenido importante solo aparece en /page#state o /page#!/view, Google normalmente lo trata como la misma URL que /page, no como un documento separado.

El impacto para el negocio es sencillo: las URLs ocultas no posicionan. Los estados de productos, artículos de ayuda, vistas de categorías filtradas y rutas de la aplicación pueden desaparecer de la búsqueda incluso cuando los usuarios pueden acceder a ellos perfectamente en el navegador.

Lo que realmente hace Google con los fragmentos

Para la indexación normal, los motores de búsqueda eliminan el fragmento. Google retiró el antiguo esquema de rastreo AJAX hace años, y eso acabó con la vieja solución con #!. En la práctica, Googlebot solicita la URL base, no cada variación de hash que se superpone a ella.

Eso significa que example.com/docs#setup no es una segunda página. Por lo general, solo es example.com/docs con un salto dentro de la página. Si tu router de React o Vue todavía depende de estados basados en hash para contenido único, tienes un problema de indexación, no un detalle técnico menor.

Una advertencia sincera: los fragmentos están bien para anclas, pestañas y enlaces de salto en una página que ya es indexable. El problema empieza cuando los equipos esperan que los fragmentos creen entradas de búsqueda independientes.

Dónde se rompe el rendimiento SEO

• SPAs que usan enrutado con hash: rutas como /#/pricing o /#!/features a menudo se consolidan en una sola URL rastreable.
• Navegación facetada: los filtros cargados solo a través de fragmentos no pueden obtener posicionamientos para combinaciones de long tail.
• Centros de documentación: los estados de artículos renderizados detrás de fragmentos a menudo no logran indexarse de forma individual.
• Confusión sobre el link equity: los backlinks a variantes con fragmentos rara vez generan señales de ranking separadas para esos estados.

En Screaming Frog, esto suele verse como una única URL HTML con muchos cambios de estado de JavaScript, pero sin rutas de rastreo distintas. En Google Search Console, ves impresiones concentradas en la URL base, mientras que las supuestas vistas hijas no reciben nada. Luego, Ahrefs y Semrush reportan menos URLs con ranking de las que el equipo de producto cree que existen.

Qué hacer en su lugar

1. Mueve los estados importantes a URLs reales usando enrutado basado en rutas (path-based) o parámetros de consulta.
2. Renderiza el contenido indexable del lado del servidor o prepresenta (pre-render) con frameworks como Next.js, Nuxt o Astro.
3. Configura canonicals en las nuevas URLs, no en las versiones con fragmentos.
4. Actualiza los enlaces internos, los XML sitemaps y la navegación para que Google pueda descubrir las nuevas rutas.
5. Valida con la Inspección de URL en GSC, rastreos renderizados en Screaming Frog y, si los tienes, con archivos de log.

Si se trata de una migración, mapea los destinos antiguos visibles para el usuario con fragmentos a URLs equivalentes rastreables cuando sea posible. Estrictamente hablando, no puedes hacer un 301 de un fragmento porque el fragmento se gestiona en el cliente, no se envía en la solicitud HTTP. Ese es el matiz que muchos glosarios omiten. Necesitas manejo con JavaScript, actualizaciones de enlaces internos y recuperación de enlaces externos en Ahrefs o Moz, no una regla de redirección limpia del lado del servidor.

En resumen: los fragmentos son para posiciones en una página, no para documentos indexables. Si la página importa para el tráfico orgánico, dale una URL real.