Crawled, Currently Not Indexed: cómo auditar calidad
Google dice que la calidad del sitio puede influir en la indexación, pero Crawled - currently not indexed exige primero una auditoría técnica.
TL;DR: `Crawled - currently not indexed` no es un diagnóstico. Es un estado dentro de Search Console. Primero haz triage técnico, agrupa URLs por plantilla e intención, y recién después pregunta si esa página merece estar en el índice aunque crawl, render, canonical e interlinking estén correctos.
Auditoría de calidad e indexación en Google
Mira el workflow de 5 minutos para Crawled - currently not indexed
Un recorrido técnico para separar problemas de crawl, render, canonical, duplicación, interlinking y calidad antes de reescribir páginas.
John Mueller y Martin Splitt dejaron una aclaración útil para SEOs: la calidad puede influir en cuántas páginas decide rastrear e indexar Google, pero calidad no significa solo texto.
Ese detalle cambia la auditoría. Una página puede tener frases únicas y aun así ser un mal resultado. Puede esconder la respuesta debajo de anuncios, cargar lento, duplicar otras URLs, depender de JavaScript frágil o existir solo porque alguien necesitaba otra URL en el calendario editorial.
Por eso no conviene entrar en pánico cuando Search Console muestra muchas URLs en `Crawled - currently not indexed`. Conviene dejar de tratar ese bucket como un solo problema. Es una cola de evidencia. Algunas URLs necesitan arreglo técnico. Algunas necesitan consolidación. Algunas necesitan mejores links internos. Algunas no deberían indexarse.
Qué Dijo Google
La conversación llegó a través de un reporte de Search Engine Journal sobre el reporte de indexación de páginas. Splitt explicó la diferencia entre `Discovered - currently not indexed` y `Crawled - currently not indexed`: en el primer caso, Google conoce la URL pero todavía no la visitó; en el segundo, Google la visitó y decidió no ponerla en el índice.
La respuesta de Mueller sobre calidad fue cuidadosa. Cuando Splitt preguntó si ese estado es señal de calidad, Mueller dijo que a veces. Ese "a veces" debería controlar toda la auditoría.
También explicó que cuando los sistemas de Google tienen preocupaciones fuertes sobre la calidad general de un sitio, Google puede rastrear menos e indexar menos. En la práctica, un patrón amplio de no indexación sin explicación técnica puede apuntar a un problema de calidad de sitio. No significa que cada URL excluida sea mala.
La parte más útil fue la definición de calidad. Mueller no habló solo de word count o unicidad textual. Habló de la experiencia completa de la página: anuncios, interstitials, relleno, layout, performance y facilidad para llegar a la información.
Haz La Auditoría Técnica Primero
Antes de diagnosticar calidad, prueba que Google puede acceder a la página y entenderla.
Empieza por cohortes, no por una URL suelta. Exporta una muestra de páginas excluidas desde Search Console y agrúpalas por plantilla, tipo de página, intención, directorio, canonical, sitemap e interlinking. Buscas patrones repetidos.
Para cada cohorte, revisa lo básico:
- Status HTTP y cadena de redirecciones.
- Robots.txt y controles `noindex`.
- Canonical y cluster de duplicados.
- Sitemap y fecha `lastmod`.
- Links internos desde páginas rastreables.
- HTML renderizado si la página depende de JavaScript.
- Duplicación, boilerplate o thinness por plantilla.
- Errores de servidor, DNS y picos de crawl.
Muchos proyectos de indexación fallan acá. Saltan de "Google la rastreó y la dejó afuera" a "Google odia nuestro contenido". Puede ser. Pero si el canonical apunta a otra URL, el contenido aparece solo después de un script frágil, la URL es una variante infinita de filtros o la página no recibe links internos, la conversación sobre calidad llega demasiado temprano.
Cuándo Calidad Se Vuelve El Diagnóstico Correcto
Calidad se vuelve el diagnóstico correcto cuando la evidencia técnica ya no explica el patrón.
Si Google puede rastrear las páginas, renderizar el contenido principal, ver el canonical correcto, llegar mediante links internos y aun así deja fuera una parte grande de una sección, la pregunta cambia. Ya no es "¿puede Google indexar esto?". Es "¿por qué debería indexarlo?".
Esa pregunta incomoda porque el dueño del sitio recuerda todo el trabajo que hubo detrás. Reuniones, briefs, cambios de diseño, razón comercial, calendario editorial. Google ve una URL compitiendo contra el resto de la web.
En auditorías de SEOFrancisco, prefiero convertir calidad en preguntas concretas:
- Intent match: ¿la página responde la intención detrás de la URL o rodea el tema?
- Valor original: ¿hay experiencia, datos, ejemplos, screenshots, framework propio o una respuesta más clara que la competencia?
- Finalización de tarea: ¿el visitante puede resolver lo que vino a hacer sin pelear con el layout?
- Valor de plantilla: ¿la plantilla crea páginas útiles a escala o genera casi duplicados?
- Prueba: ¿las afirmaciones tienen evidencia visible, fuentes, tests o ejemplos específicos?
- Experiencia de página: ¿el contenido principal se puede leer y usar en mobile y desktop?
El contenido creado con IA puede entrar en esta revisión, pero como ejemplo. El problema no es que una IA haya tocado el draft. El problema son páginas intercambiables, sin prueba y sin nada que un usuario no consiga en otros diez resultados. Un texto humano de relleno puede fallar igual.
Calidad Es Toda La Página
La guía de Google sobre contenido útil y centrado en personas ya empuja a evaluar utilidad, confiabilidad y valor. La conversación sobre indexación suma algo operativo: el contenedor de la página también importa.
Una página puede perder la discusión de calidad antes del primer párrafo. Ads intrusivos, cambios bruscos de layout, scripts pesados, media innecesaria, navegación confusa y mucho relleno antes de la respuesta cambian la experiencia real.
Eso no significa que cada problema de Core Web Vitals explique la no indexación. Significa que la experiencia de página pertenece a la auditoría de calidad, no a un bucket cosmético separado. La guía de Google sobre page experience ayuda a revisar si los usuarios pueden acceder y usar la página cómodamente.
El Workflow Por Cohortes
No empieces con una URL y una captura. Construye una muestra.
Exporta URLs afectadas desde Search Console y crea cohortes. Para un sitio mediano o grande, las separaría así:
| Cohorte | Qué revisar primero | Acción probable |
|---|---|---|
| URLs nuevas | Fecha de descubrimiento, sitemap, links internos, crawl | Esperar, reforzar links o pedir indexación después de validar |
| Páginas de plantilla | Duplicación, canonicals, boilerplate débil | Consolidar, mejorar la plantilla o noindexar variantes pobres |
| Artículos editoriales | Originalidad, intención, prueba, interlinking | Reescribir con una respuesta más fuerte y evidencia |
| Páginas con JavaScript | HTML inicial, HTML renderizado, recursos bloqueados | Mover contenido crítico a HTML rastreable o arreglar render |
| Facetas o parámetros | Trampas de crawl, duplicados, canonical y robots | Controlar rutas de crawl y consolidar duplicados |
Luego puntúa cada cohorte en dos ejes: confianza técnica y valor de indexación. Una página con baja confianza técnica necesita trabajo de ingeniería o arquitectura. Una página técnicamente accesible pero con bajo valor necesita edición, consolidación o un cambio de plantilla.
El peor punto medio es una página accesible que no dice nada nuevo. Ahí los equipos suelen pedir indexación, agregar párrafos y refrescar la fecha. Si la página no le da a Google una razón para conservarla, esos rituales no crean una.
Qué Arreglar Antes De Pedir Indexación
Pide indexación después de un cambio que importe.
Para un problema técnico, puede ser un canonical corregido, un link interno rastreable, un render arreglado, un status code limpio o un `noindex` accidental eliminado. Para un problema de calidad, significa que la página tiene una razón más fuerte para existir: mejor intención, evidencia original, estructura más clara, acceso más rápido a la respuesta, menos relleno o consolidación con una URL mejor.
Usa URL Inspection para URLs representativas, no como botón mágico masivo. Si una plantilla tiene 4,000 páginas excluidas, inspecciona muestras de cada patrón, documenta el arreglo, valida la URL en vivo y monitorea la cohorte. El objetivo no es forzar una página al índice. Es hacer que el patrón merezca indexarse.
Para páginas con mucho JavaScript, combínalo con revisiones de HTML renderizado. Nuestra auditoría de JavaScript y asistentes de IA muestra por qué el HTML inicial y el renderizado pueden contar historias distintas. Para páginas orientadas a agentes, la discusión sobre agentic browsing y llms.txt apunta al mismo principio: las máquinas necesitan páginas que puedan inspeccionar sin adivinar.
El Takeaway Práctico
El comentario de Mueller no debería convertir cada problema de indexación en una discusión vaga sobre calidad. Debería hacer la auditoría más disciplinada.
Usa Search Console para encontrar el patrón. Usa checks técnicos para eliminar falsas causas. Después juzga si las páginas restantes merecen indexación desde la perspectiva de un usuario. Si la merecen, refuerza la evidencia y haz la página más usable. Si no, consolida, noindexa, redirige o déjalas fuera del índice a propósito.
Preguntas frecuentes
¿Crawled - currently not indexed siempre significa mala calidad?
No. Puede venir de problemas técnicos, duplicación, canonicals, interlinking débil, priorización de crawl, procesamiento temporal o calidad. Es un estado que requiere investigación.
¿Cuándo debo auditar calidad?
Después de descartar problemas de acceso, render, canonical, duplicación, sitemap, links internos y servidor en una cohorte representativa de URLs.
¿Google usa bounce rate o dwell time para decidir indexación?
Esta conversación no confirmó un uso directo de bounce rate, dwell time o back button. El aprendizaje seguro es que Google evalúa la experiencia completa de la página y la utilidad del contenido.
¿El contenido con IA puede causar este estado?
No automáticamente. El riesgo está en páginas genéricas, sin valor único, prueba o experiencia útil, hayan sido escritas por IA o por una persona.
¿Conviene pedir indexación después de cada cambio?
Pide indexación después de validar un arreglo real. Para patrones grandes, inspecciona URLs representativas y monitorea la cohorte.
About the Author
